Re: [mpls] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt
Loa Andersson <[email protected]> Thu, 20 Apr 2023 20:29:40 +0200
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.mpls |
|---|---|
| Message-ID | <[email protected]> |
Greg, inline please. On 2023-04-20 20:17, Greg Mirsky wrote: > Hi Loa, > but for the non-MNA node to get to the payload, it first must dispose of > NAS. Yeah I thought about that and is not clear how it works. How does a non-MNA capable node "dispose" on MNA LSEs? If that is the case, then it will certainly encounter the MNA > bSPL, and drop the packet before going to the payload. Am I missing > something? Well, if it encounters an Ethernet Pseudowire without a control word then the packet is not dropped even if the nibble has the same value that we assign for MNA, right? How does the node distinguish between an MNA first nibble and the first nibble in such a Pseudowire? > As I understand the use of a new first nibble in PSD MNA, that is to > avoid boxes that use the payload for load-balancing. WE are only doing load balancing if the first nibble is 4 or 6, right? To avoid load balancing we could just set it to zero. /Loa > > Regards, > Greg > > On Thu, Apr 20, 2023, 8:11 PM Loa Andersson <[email protected] > <mailto:[email protected]>> wrote: > > Tony, > > I think I'm beginning to understand yoor argument(s). > > If I understand correctly you are saying that there are MNA capable > implementations and non-MNA capable implementations. > > An MNA capable implementation will find the MNA Label, will look in the > second LSE, find the P bit set and understand that there is PSD after > the stack. That implementation can then go ahead, skip the 1st nibble, > and go directly to process the PSD found immediately after the first > nibble. > > An non-MPLS capable implementation will find the first nibble (that is > marked "PSD"), understand that it is not able to handle this data and > do whatever is required. > > A couple of questions > > - will a non-MNA capable implementation have problems "processing" (aka > as skipping over) the MNA label and the extra LSEs after the MNA Label? > How does it know what is an extra LSE and what is a Label? > > - we will only include the MNA first nibble if there is an MPLS > Label in > the packet. right? Existing (legacy) non-MMA capable implementations > will not recognize the MNA first nibble as "MNA follows, only > understand > that this is something unrecognised. What does legacy > implementations do > with unrecognized first nibbles today? > > - are there cases where PSD does not immediately follow the first > nibble? > > - shouldn't the behaviour in these two cases be documented in one of > our > drafts? > > /Loa > > On 2023-04-20 17:10, Tony Li wrote: > > > > Hi Loa, > > > > I don’t understand your question. > > > > Please recall that we have to deal with legacy implementations. > We need PSD quickly and efficiently found by implementations that > support MNA. The pointer in ISD helps with that. > > > > We also need to ensure that MNA PSD is not confused with other > PSD usages. The new first nibble is a requirement for that. > > > > Tony > > > > > >> On Apr 20, 2023, at 2:20 AM, Loa Andersson <[email protected] > <mailto:[email protected]>> wrote: > >> > >> Authors, Working Group, > >> > >> It is is a mystery to me why adding a new first nibble that is > not precise, rather than to trust the the P-bit in the LSE following > the MNA label: > >> > >> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Opcode | Data |P|IHS|S| Res |U| NASL | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> which give you a precise pointer to the PSD, is not considered > "cleaner" than trusting the first nibble. > >> > >> /Loa > >> > >> On 2023-03-28 22:58, Rakesh Gandhi wrote: > >>> Hi Loa, > >>> We, authors, feel that having a new first Nibble IANA assigned > would be a cleaner solution, but we also like to hear from the other > side of the house. > >>> Thanks, > >>> Rakesh > >>> On Fri, Mar 17, 2023 at 3:56 AM Loa Andersson <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: > >>> Rakesh, > >>> Thanks for response, I'd like to point out > >>> - the first nibble is never on its own a sufficient > indication for what > >>> the payload a a packet is, it might be an Ethernet PW > without > >>> control > >>> word, where the first nibble accidentally is a value > that we > >>> assigned > >>> for some payload. > >>> - something more is needed to with sufficient accuracy > understand what > >>> the payload is, for PSD this is the P-bit in the OpCode > LSE. > >>> - actually the the P-bit in the OpCode LSE is sufficient in > itself, we > >>> don't need the first nibble, unless we for some reason > want both > >>> brace and waist belt, but I can't see why > >>> - first nibbles is a scarce resource that should only be > allocated if we > >>> really need it. > >>> Maybe someone from the the pseudo wire side of the house > can confirm > >>> this. > >>> /Loa > >>> On 2023-03-15 13:16, Rakesh Gandhi wrote: > >>> > Hi Loa, > >>> > > >>> > Authors discussed the first nibble after BOS. > >>> > Re-using any existing Nibble (e.g. 0000b for CW or 0001b for > >>> G-ACH) can > >>> > lead to backwards compatibility issues on the legacy > devices. > >>> > Note that legacy devices may not support MNA sub-stack. > >>> > It would be good to assign a new nibble (e.g., 0x2 = 0010b, > >>> currently > >>> > not assigned) to avoid such issues. > >>> > We can agree on this (i.e. assigning a new nibble for > PSD), we can > >>> > update the draft accordingly. > >>> > > >>> > thanks, > >>> > Rakesh > >>> > > >>> > > >>> > > >>> > > >>> > On Fri, Mar 10, 2023 at 9:40 AM Loa Andersson > >>> <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > >>> > > >>> > All, > >>> > > >>> > I have a question that is not new, and I’m still > uncertain > >>> what the > >>> > correct answer is. > >>> > > >>> > I’m not certain that we should consider “the first > nibble” as > >>> part > >>> > of the MNA PSD. Admittedly it is part of PSD, but > not part of the > >>> > MNA PSD. > >>> > > >>> > We could say that MNA PSD start after the first > nibble. If the > >>> > PSD-bit is set in the MNA-label LSE, we can safely > ignore the > >>> first > >>> > nibble, if it is not set we need to look at the > first nibble, and > >>> > the data following the first nibble is not MNA > ancillary data. > >>> > > >>> > I see no meed to define a PSD first nibble. It would > also avoid a > >>> > potential ambiguity in using the Generic Associated > Channel > >>> nibble. > >>> > > >>> > For MNA the first should be set to 0000b when sent, and > >>> ignored when > >>> > received. > >>> > > >>> > /Loa > >>> > > >>> > Sent from my iPhone > >>> > > >>> >> On 10 Mar 2023, at 13:59, Jaganbabu Rajamanickam > (jrajaman) > >>> >> <[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] > <mailto:[email protected]>> > >>> >> <mailto:[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > >>> >> > >>> >> > >>> >> > >>> >> Hello Everyone,____ > >>> >> > >>> >> __ __ > >>> >> > >>> >> We like to introduce our new draft on Post-Stack MNA > >>> solution.____ > >>> >> > >>> >> Welcome your review comments and suggestions.____ > >>> >> > >>> >> __ __ > >>> >> > >>> >> Thanx,____ > >>> >> > >>> >> Jags____ > >>> >> > >>> >> __ __ > >>> >> > >>> >> *From: *[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] > <mailto:[email protected]>>> > >>> >> <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > >>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>> > >>> >> *Date: *Friday, March 10, 2023 at 7:52 AM > >>> >> *To: *Jaganbabu Rajamanickam (jrajaman) > <[email protected] <mailto:[email protected]> > >>> <mailto:[email protected] <mailto:[email protected]>> > >>> >> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>>, > >>> Jie Dong <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> >> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>>, > >>> Rakesh Gandhi (rgandhi) > >>> >> <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>>, Royi Zigler > >>> >> <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > >>> <mailto:[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] > <mailto:[email protected]>>>>, Tony > >>> >> Li <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> > >>> >> *Subject: *New Version Notification for > >>> >> draft-jags-mpls-ps-mna-hdr-00.txt____ > >>> >> > >>> >> > >>> >> A new version of I-D, draft-jags-mpls-ps-mna-hdr-00.txt > >>> >> has been successfully submitted by Jaganbabu > Rajamanickam and > >>> >> posted to the > >>> >> IETF repository. > >>> >> > >>> >> Name: draft-jags-mpls-ps-mna-hdr > >>> >> Revision: 00 > >>> >> Title: Post-Stack MPLS Network Action > (MNA) Solution > >>> >> Document date: 2023-03-10 > >>> >> Group: Individual Submission > >>> >> Pages: 17 > >>> >> URL: > >>> >> > >>> > https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt> > >>> > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt>> > >>> >> > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt> > >>> > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.txt>>> > >>> >> Status: > >>> >> > https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/ > <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/> > >>> > <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/ > <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/>> > >>> >> > <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/ > <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/> > >>> > <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/ > <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/>>> > >>> >> Html: > >>> >> > >>> > https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html> > >>> > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html>> > >>> >> > <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html> <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html <https://www.ietf.org/archive/id/draft-jags-mpls-ps-mna-hdr-00.html>>> > >>> >> Htmlized: > >>> >> > https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr > <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr> > >>> > <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr > <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr>> > >>> >> > <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr > <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr> > >>> > <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr > <https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-mna-hdr>>> > >>> >> > >>> >> > >>> >> Abstract: > >>> >> This document defines the Post-Stack MPLS > Network Action > >>> (MNA) > >>> >> solution for carrying Network Actions and > Ancillary Data > >>> after the > >>> >> MPLS label stack based on In-Stack MNA solution > defined > >>> in draft- > >>> >> ietf-mpls-mna-hdr. MPLS Network Actions can be > used to > >>> influence > >>> >> packet forwarding decisions, carry additional > OAM information > >>> >> in the > >>> >> MPLS packet or perform user-defined operations. > This > >>> document > >>> >> addresses the MNA requirements specified in > >>> draft-ietf-mpls-mna- > >>> >> requirements. This document follows the MNA > framework > >>> specified in > >>> >> draft-ietf-mpls-mna-fwk. > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> The IETF Secretariat > >>> >> > >>> >> ____ > >>> >> > >>> >> _______________________________________________ > >>> >> mpls mailing list > >>> >> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] <mailto:[email protected]>>> > >>> >> https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls> > >>> <https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls>> > >>> >> <https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls> > >>> <https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls>>> > >>> > _______________________________________________ > >>> > mpls mailing list > >>> > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] <mailto:[email protected]>>> > >>> > https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls> > >>> <https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls>> > >>> > <https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls> > >>> <https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls>>> > >>> > > >>> > > >>> > _______________________________________________ > >>> > Pals mailing list > >>> > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> > https://www.ietf.org/mailman/listinfo/pals > <https://www.ietf.org/mailman/listinfo/pals> > >>> <https://www.ietf.org/mailman/listinfo/pals > <https://www.ietf.org/mailman/listinfo/pals>> > >>> -- Loa Andersson email: > [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > >>> Senior MPLS Expert [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > >>> Bronze Dragon Consulting phone: +46 739 81 21 64 > >> > >> -- > >> Loa Andersson email: [email protected] > <mailto:[email protected]> > >> Senior MPLS Expert [email protected] <mailto:[email protected]> > >> Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > -- > Loa Andersson email: [email protected] <mailto:[email protected]> > Senior MPLS Expert [email protected] <mailto:[email protected]> > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > Pals mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/pals > <https://www.ietf.org/mailman/listinfo/pals> > -- Loa Andersson email: [email protected] Senior MPLS Expert [email protected] Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ Pals mailing list [email protected] https://www.ietf.org/mailman/listinfo/pals