Re: [mpls] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt
Greg Mirsky <[email protected]> Thu, 20 Apr 2023 20:17:42 +0200
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.mpls |
|---|---|
| Message-ID | <CA+RyBmUkzkQ=TtK4nzRzCdVOZVAs=dip0F3mkyeLQqRZ2CCFnA@mail.gmail.com> |
Hi Loa, but for the non-MNA node to get to the payload, it first must dispose of NAS. 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? 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. Regards, Greg On Thu, Apr 20, 2023, 8:11 PM Loa Andersson <[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]> 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]>> 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]>>> > 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]>>> 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]>> > >>> >> <[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]>>>, > >>> Jie Dong <[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]>>>, Royi > Zigler > >>> >> <[email protected] <mailto:[email protected] > > > >>> <mailto:[email protected] > >>> <mailto:[email protected]>>>, Tony > >>> >> Li <[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 > >> > >>> >> 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/>> > >>> >> 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 > >> > >>> >> > >>> >> > >>> >> 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]>> > >>> >> 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]>> > >>> > 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]> > >>> > https://www.ietf.org/mailman/listinfo/pals > >>> <https://www.ietf.org/mailman/listinfo/pals> > >>> -- 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] > >> Senior MPLS Expert [email protected] > >> Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > -- > 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 > _______________________________________________ Pals mailing list [email protected] https://www.ietf.org/mailman/listinfo/pals