Re: [mpls] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt
Tony Li <[email protected]> Tue, 25 Apr 2023 12:33:54 -0700
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.mpls |
|---|---|
| Message-ID | <[email protected]> |
Hi Greg, Sorry for the delay. >> If a transit node needs to find PSD, it can scan the entire label stack for the bottom of stack bit. I can’t think of a good reason to ever do this, given that it’s a transit node and should be payload indifferent. > GIM>> I got confused. I am too not seeing the case when an LSR starts looking for PSD unless it has found a proper NAS. I’m told that some legacy transit nodes choose to look at the payload to extract ECMP. A legacy implementation that does this and finds any MNA PSD is going to be mightily confused and would never see MNA ISD. An MNA specific nibble here would be helpful in ensuring that it realizes that it’s about to make a mistake. >> > - 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? >> >> >> There is not much point in having an MNA first nibble unless there is also MNA PSD. And there is not much point in MNA PSD unless there is a label stack involved. Therefore, yes, there should be a label in the label stack. > GIM>> More confusion in my head. Why it must be "an MNA first nibble" but not any non-IPv4 and non-IPv6? Just for clear semantics. I am a very big fan of avoiding overloading. Tony _______________________________________________ Pals mailing list [email protected] https://www.ietf.org/mailman/listinfo/pals