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

Loa Andersson <[email protected]> Thu, 27 Apr 2023 09:03:34 +0200
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