Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

[Alexander Vainshtein <[e-mail]>]

Loa and all,

I have to admit that I have not been following the work of the DT closely for the last month or so.

Therefore I may be asking some questions that have already been asked and even answered. In which case you can simply say so(hopefully with some reference).

However I still think these questions should be asked.

Please see these questions - with some clarifications - inline below.





Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]



-----Original Message-----
From: mpls <[e-mail]> On Behalf Of Loa Andersson
Sent: Tuesday, June 15, 2021 3:31 PM
To: [e-mail]
Subject: [EXTERNAL] [mpls] Indicators in the stack and ancillary data after the BoS



Design Team,



When the Associated Channel first were desing it was assume that one associated channel per packet would be enough for the future.

[[Sasha]] Actually the initial GACh design (RFC 5586<https://datatracker.ietf.org/doc/html/rfc5586>) has provided for a TLV to follow the GACh fixed header, with the provision that the presence of such a TLV is inferred from the GACh type in the fixed header. However, this mechanism has never been used, and eventually GACh TLVs have been retired (RFC 7026<https://datatracker.ietf.org/doc/html/rfc7026>).

I wonder if the need for multiple GACh in a packet could be addressed by GACh TLVs?



The rules for where the GAL (indicator for an associated channel) should be located in the stack and that there could only be one GAL in the stack was strictly specified.

[[Sasha]] GAL has been restricted to be just the BoS label in the MPLS-TP environments, but this restriction does not apply  "to other environments".

However, I am not aware of any rules for handling GAL if it is exposed to the MPLS forwarder (i.e. becomes top of the stack) while being followed by some other labels. RFC 5586 only says that "A receiving LSR, LER, or PE MUST NOT forward a G-ACh packet to  another node based on the GAL label". This is quite different from the definition of handling for the Routing Alert label. From my POV:

*         Lack of these definitions effectively precludes usage of GAL in a non-BoS position

*         Any such definition, if introduced today, will not be backward compatible with the existing implementations.



Now we are where the development has taken us to a point where the GAL can be found at almost any position in the stack.

[[Sasha]] Please see my previous comment.



Further changes are discussed.



- As label stack has been growing there is a risk that some LSRs that

   need to find the GAL might find that the GAL is below readable depth.

   The proposed remedy is to allow entering a copy of the first GAL

   higher in the stack, i.e. more than one GAL in the stack point to the

   same ACH.[[Sasha]] The LSR normally looks just at the top label in the stack. If GAL is not in the top position, why should it react to it? And if it is in the top position but not BoS, how will the packet be forwarded? In addition, GAL does not "point to an ACH". It says that ACH immediately follows the BoS label, so I fail to understand how a GAL can point to a specific ACH.



- It has also been discussed to carry more than one ACH after the BoS,

   i.e. you'll need more than one different GALs in the stack pointing to

   different ACH's.[[Sasha]] By different GALs do you mean different reserved - or extended reserved - label values?

   (I think the if this statement is true that would require a "slight",

   but backwards compatible redesign of the GAL.)



- It has also been discussed to carry more then set of (the ACH is one)

   ancillary data after the BoS, and e.g. FAI, GAL, EHI, OAM indicator,

   etc. mixed in the label stack.



The issue is that the set of ancillary data after the BoS might will interfere and that we need a strong mechanism to find the ancillary data that "belongs to" a certain indicator.



I think that we first need to decide what is required and after that design a solution.



The correctness of statements about need to be verified and if necessary corrected.



/Loa



PS



Can someone tell me if I should use anxillary or ancillary?





--



Loa Andersson                        email: [e-mail]<mailto:[e-mail]>

Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>

Bronze Dragon Consulting             phone: [phone]



_______________________________________________

mpls mailing list

[e-mail]<mailto:[e-mail]>

https://clicktime.symantec.com/389rPq1ADpF9WRstEF2jdmj6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls



Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.