Subject: Re: MPLS PID

From: George Swallow <[email-masked]>
Date: Wed, 26 Mar 2003 13:51:26 -0500

> How does requiring a PID in the PWE3 L2 control word solve or handle the 
> case where a control word is not mandatory?

It doesn't.  But it does give an operator concerned with ECMP and flow
identification a means of doing it.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Luca Martini <[email-masked]>
Date: Thu, 27 Mar 2003 17:55:42 -0700

> case where a control word is not mandatory?
some networks might not care.
Lcua

> There are pseudo-wires, such as ethernet, where a control word is not 
> mandatory.  This would imply that the first nibble (which would be 
> identified as the suggested PID) would be that from the ethernet frame.
> 
> Alia
> 
> At 01:53 PM 3/25/2003 -0700, Danny McPherson wrote:
> 
>> [Note the cross-post, let's try to move this to MPLS please]
>>
>> I tend to agree with Mark & George (and others) that it should
>> be addressed in the MPLS WG, with feedback from PWE3.
>>
>> PWE3 Architecture and perhaps Requirements (ugh!) work should be
>> added as appropriate, please send your comments on what needs to
>> be done there ASAP, if you haven't already.
>>
>> -danny
>>
>>
>> >
>> > I agree too that the PID issue is more of an MPLS issue in general. 
>> As such, the
>> > I think the MPLS WG should be tasked with defining exactly what the 
>> PID looks
>> > like, and what internode behavior relying on the PID is allowed.
>> >
>> > However, the PWE3 architecture cannot ignore this entirely. It is 
>> PWE3's direct
>> > use of MPLS as its own PSN more than anything else that is imposing 
>> this
>> > practical requirement now (though I suppose it has theoretically 
>> always been an
>> > issue), and any definition coming from the MPLS WG would likely be 
>> in the form
>> > of a requirement on any header definition that rides directly 
>> adjacent to the
>> > last MPLS label in a stack. We all know that this would probably 
>> look something
>> > like simply stating that the first four bits MUST be 4 for IPv4, 6 
>> for IPv6, and
>> > up to IANA and the MPLS WG for future additions. Whether that means 
>> handing out
>> > values form the remaining 14 available under very tight control (at 
>> a minimum,
>> > via an RFC2434 Standards Action and the MPLS WGs blessing), or some 
>> other
>> > extended PID method, should be up to MPLS to ultimately decide and 
>> PWE3 to
>> > adhere to. This would all be done with PWE3's input of course, since 
>> there would
>> > be a lot of overlap in the folks making the decision.
>> >
>> > Regarding whether the MPLS WG has discussed this before, Eric Rosen 
>> suggested at
>> > the microphone in SF that it had, but at that time the decision 
>> obviously was to
>> > not include a PID within MPLS. The bottom line is that perhaps we 
>> are seeing
>> > that in hindsight this was an error, and if so this should be openly 
>> resolved
>> > within the MPLS WG.
>> >
>> > - Mark
>> >
>> > Andrew G. Malis wrote:
>> > > I would just like to second Ron's questions below, and also add that
>> > > there's no mention of the need for a protocol identification field in
>> > > the PWE3 requirements draft.
>> > >
>> > > Also, I noticed that the architecture draft had no recognition of the
>> > > TDM control word format; it only discussed the control word used 
>> for L2
>> > > encapsulations.
>> > >
>> > > So, I would like to request the following change in
>> > > draft-ietf-pwe3-arch-02.txt:
>> > >
>> > > 5.4.3. PW over MPLS Generic Control Word
>> > >
>> > >    The PW set-up protocol determines whether a particular PW uses a
>> > >    control word.  When a control word is used, it MUST have the
>> > >    following form for non-TDM encapsulations:
>> > >
>> > >        0                   1                   2                   3
>> > >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 
>> 0 1
>> > >       
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >       |   RSVD/Flags  |FRG|  Length   | Sequence 
>> Number               |
>> > >       
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >
>> > >         Figure 12 - MPLS Generic Control Word
>> > >
>> > >
>> > >    The meaning of the fields of the MPLS Generic Control Word (Figure
>> > >    12) is as follows:
>> > >
>> > >        RSVD/Flags (bits 0 to 7):
>> > >            These bits are available for per payload signaling. Their
>> > >            definition is encapsulation specific.  If not all of 
>> the bits
>> > >            are required for flags, some may be reserved for future 
>> use.
>> > >
>> > >        FRG (bits 8 and 9):
>> > >            These bits are used when fragmenting a PW payload. 
>> Their use
>> > >            is defined in [FRAG].
>> > >
>> > >        Length (bits 10 to 15):
>> > >            The length field is used to determine the size of a PW
>> > >            payload that might have been padded to the minimum 
>> Ethernet
>> > >            MAC frame size during its transit across the PSN.  If the
>> > >            MPLS payload (defined as the CW + the PW payload + any
>> > >            additional PW headers is less than 46 bytes, the length 
>> MUST
>> > >            be set to the length of the MPLS payload.  If the MPLS
>> > >            payload is between 46 bytes and 63 bytes the 
>> implementation
>> > >            MAY either set to the length to the length of the MPLS
>> > >            payload, or it MAY set it to 0.  If the length of the MPLS
>> > >            payload is greater than 63 bytes the length MUST be set 
>> to 0.
>> > >
>> > >        Sequence number (Bit 16 to 31):
>> > >            If the sequence number is not used, it is set to zero by
>> > >            the sender and ignored by the receiver.  Otherwise it
>> > >            specifies the sequence number of a packet. A circular list
>> > >            of sequence numbers is used. A sequence number takes a 
>> value
>> > >            from 1 to 65535 (2**16-1).
>> > >
>> > > For TDM applications, it must use the following general forms.
>> > >
>> > > Non-extended form:
>> > >     0                   1                   2                   3
>> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    |0| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >
>> > > Extended form:
>> > >     0                   1                   2                   3
>> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    |1| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    |         Additional encapsulation-specific header fields       |
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >
>> > >    Structure Pointer[0:12]: If used, the Structure Pointer 
>> contains the
>> > >    offset of the first byte of the payload structure.  Note that some
>> > >    TDM encapsulations do not require the use of a Structure Pointer,
>> > >    in which case this field may be reused for other uses.
>> > >
>> > >    Sequence Number[0:13]:  This is a packet sequence number, which
>> > >    continuously cycles from 0 to 0x3FFF.  It is generated and 
>> processed
>> > >    in accordance with the rules established in [RFC1889].  When 
>> the RTP
>> > >    header is used, this sequence number MUST match the LSBs of the 
>> RTP
>> > >    sequence Number.
>> > >
>> > > Thanks,
>> > > Andy
>> > >
>> > > -------
>> > >
>> > > At 3/23/2003 10:04 AM +0200, Ron Cohen wrote:
>> > >
>> > >> Stewart,
>> > >>
>> > >> I went over your SF arch presentation. I have doubts regarding the
>> > >> introduction of a requirement/suggestion for an all zero PID field
>> > >> within the PWE3 control word. My doubts relates both to the scope of
>> > >> this work as well as for the applications you are describing. 
>> Since I
>> > >> haven't been to the SF IETF, please forgive me in advance if these
>> > >> issues have already been discussed.
>> > >>
>> > >>
>> > >> MPLS PID scope:
>> > >> --------------
>> > >> In your presentation you describe a requirement/suggestion for an 
>> MPLS
>> > >> PID, that allows a network node to distinguish between an IPv4, 
>> IPv6 and
>> > >> PWE3 stream. The Multi-Protocol part of MPLS stands for carrying any
>> > >> network protocol on top of MPLS, including possibly IPX, CLNS, etc.
>> > >> Therefore, what you are proposing is introduction of an MPLS 
>> Protocol
>> > >> Identifier, which I believe has a much larger scope than just the 
>> PWE3
>> > >> WG.
>> > >>
>> > >> 1. Would you agree that this is an MPLS WG item? Has this 
>> requirement
>> > >> (MPLS PID) been discussed in the MPLS WG before / are there any 
>> drafts
>> > >> written?
>> > >>
>> > >> 2. If so, would 4 bits suffice for an MPLS PID?
>> > >>
>> > >>
>> > >> Applications:
>> > >> ------------
>> > >> You list a number of applications that require IP flow recognition,
>> > >> including load balancing, billing, and protection against network 
>> abuse
>> > >> and attacks. I would like to better understand if these applications
>> > >> indeed require the introduction of the PID field. For example, 
>> are these
>> > >> applications edge applications? Do these applications run on all 
>> LSPs,
>> > >> or are sensitive to BE LSP vs. LSP with priority? Do you run these
>> > >> applications on TE paths?
>> > >>
>> > >> 1. Are there any drafts that describe these applications?
>> > >>
>> > >> 2. If not, could you elaborate on each application, its scope, etc?
>> > >>
>> > >>
>> > >> Thanks
>> > >> Ron
>> > >>
>> > >> Ron Cohen
>> > >> CTO
>> > >> Lycium Networks
>> > >> Desk: +972 9 7619004
>> > >> Mobile: +972 55 245104
>> > >> Fax: +972 9 7619022
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> pwe3 mailing list
>> > >> [email-masked]
>> > >> https://www1.ietf.org/mailman/listinfo/pwe3
>> > >
>> > >
>> > > _______________________________________________
>> > > pwe3 mailing list
>> > > [email-masked]
>> > > https://www1.ietf.org/mailman/listinfo/pwe3
>> > >
>> >
>> > _______________________________________________
>> > pwe3 mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
>