Re: [Detnet] [mpls] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt

Loa Andersson <[email protected]>
Newsgroups gmane.ietf.pwe3,gmane.ietf.mpls
Message-ID <[email protected]>
Tony, Greg,

IN line please.

On 2023-04-25 21:33, Tony Li wrote:
> 
> 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.

I agree with Tony that simple is good.

However, Ethernet PWs without a control word made it "un-simple"!

An Ethernet PW without a control word cab put any value in the first nibble.

The consequence is e.g. MNA PSD can not rely on the first nibble only to 
identify MNA PSD.

The P flag in the LSE following the MNA will uniquely identify MNA PSD.

Now there are two possibilities

1. we assign a MNA PSD first nibble

    - if we do so an MNA PSD capable node cannot rely solely on that
      first nibble to positively identify MNA PSD
    - a node that are looking at the first nibble to decide if it can
      do load balancing does not need to understand the MNA label or
      the P flag, it can look at the first nibble to decide that it
      should not do load balancing, the first nibble will be other
      than 4 or 6.

2. we do not assign a a MNA PSD first nibble

    - if we do so an MNA PSD capable node will rely only on the P flag
      to identify MNA PSD, we can mandate that a node sending MNA PSD
      shall put a specific value (other than 4 or 6) in the first nibble
      (zero comes to mind). We can further mandate an MNA PSD capable
      node shall ignore the first nibble.
    - a node that are looking at the first nibble to decide if it can
      do load balancing does not need to understand the MNA label or
      the P flag, it can look at the first nibble to decide that it
      should not do load balancing, the first nibble will be other
      than 4 or 6.

I think we need to decide which method we use.

It should be described in detailed in the first nibble draft.

Any solution that assign a first nibble or mandate that the first nibble 
is ignored, should reference that text in the first nibble draft.


/Loa

PS

I'm a bit concerned using the option 1. since the first nibble values is 
a scarce resource.


> 
> Tony
> 
> 
> 
> _______________________________________________
> detnet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/detnet

-- 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.