Re: [mpls] Thoughts on Ancillary Data Indicators.

[Loa Andersson <[e-mail]>]

John,

Tou are right, this is an alternative.

However I tried not prescribe solutions, but address what we will 
require form such solutions.

It has be pointed out that I partly failed to dp and sometimes assumed a 
solution. It should be noted the the text is for discussion and 
improvement.

/Loa


On 08/07/2021 15:28, John E Drake wrote:
> Loa,
> 
> Another possibility is to have an FAI special purpose label in which the TTL/TC bits are intact followed by another label in which the TTL/TC bits are also intact but in which the twenty bit label field has been turned into a set of twenty bit flags.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -----Original Message-----
>> From: mpls <[e-mail]> On Behalf Of Loa Andersson
>> Sent: Thursday, July 8, 2021 5:11 AM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]; DetNet
>> Chairs <[e-mail]>
>> Subject: [mpls] Thoughts on Ancillary Data Indicators.
>>
>> [External Email. Be cautious of content]
>>
>>
>> Design Team,
>>
>> We have discussed how to carry ancillary data in  in an MPLS packet and how to
>> include indicators on the presences of such data in the label stack since the
>> design team started. I think we have some convergence and that it is time to
>> float an idea that could be the basis for a consensus. Please note that the actual
>> consensus call will be made on the mpls wg mailing list, while this is for
>> discussion preparing such a consensus call in the design team.
>>
>> The proposals we have for indicators often rely on assignment of a base special
>> purpose label. The number of such labels are limited.
>>
>> I think we can agree on the following:
>>
>> - We want to limit the number of new assignments of base special purpose
>>     labels as much as possible
>>
>> - We have a standardized associated channel, the GAL/GACH. We are not
>>     going to change the associated channel. The associated will remain as
>>     specified in RFC 5586. The ACH is found immediately after the label
>>     carrying the Bottom of Stack (BoS) bit.
>>
>> - We therefore need a (base) special purpose label to serve as the
>>     forwarding action indicator carrier.
>>
>> - It is attractive to "re-purpose" the ELI to also fill the role as a
>>     general (generic?) forwarding action indicator. This may be done by
>>     using the TTL and TC fields of the ELI as flags indicating which
>>     service is requested.
>>
>>     However, in order to do this it must be shown that there is no
>>     potential interference between the normal service supplied by the
>>     ELI/EL and the services indicated by the flags.
>>
>> - If we can't demonstrate the non-interference then we should assign
>>     specific forwarding indicator action base special purpose label and
>>     leave the ELI/EL unchanged.
>>
>> - The flag field of the re-purposed ELI of the the specially assigned
>>     forwarding action indicator label must be made extendable. These
>>     labels "only" have 11 bits (8 bit TTL and 3 bit TC fields) that can
>>     be used as flags. Already in the very preliminary discussions we have
>>     had so far are almost using all the 11 bits, making the it necessary
>>     to make the indicator extendable.
>>
>> /Loa
>>
>>
>>
>> --
>>
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Bronze Dragon Consulting             phone: [phone]
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
>> NEt6yMaO-gk!TT41je-3_SvAKNifs5hqIDE9r8daiUPp6rJSGPeoxwsM10P_yX-
>> zttu4FhZtw6E$

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]