Re: [spring] to drop or to forward unlabeled (Re: Question on RFC8660)

[Alexander Vainshtein <[e-mail]>]

Jeff, Bruno, Martin and all,
I definitely concur with Jeff: Drop should be the default MUST-to-implement behavior.
What's more, it looks to me as the only possible behavior if the problematic label is not BoS. 

And even if popping of the problematic BoS label is allowed by local configuration, some mechanism for identifying the resulting packet as IPv4 or IPv6  (or neither - I am aware of at least one vendor who has implemented native L2 transport directly over LSPs without "service labels" years ago), should be used.   

My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

-----Original Message-----
From: spring <[e-mail]> On Behalf Of Jeff Tantsura
Sent: Wednesday, September 9, 2020 11:38 AM
To: [e-mail]
Cc: [e-mail]; Martin Horneffer <[e-mail]>
Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)

I’m with Bruno here, and the spec is quite clear on the behavior expected (implementors, please speak up).
Given variability and interdependencies in use cases, I’d say, drop should be (and de-jure it is) the default behavior, and if someone wants their vendor of choice to implement a knob to change that - they are free to do so (local behavior) as long as consequences are well understood (rope is short).

Cheers,
Jeff

> On Sep 4, 2020, at 17:49, [e-mail] wrote:
> 
> Hi Martin,
> 
>> From: spring [mailto:[e-mail]] On Behalf Of Martin 
>> Horneffer
>> 
>> Hello everyone,
>> 
>> may I come back the the question below? Or rather let me update it a little:
>> 
>> In case an SR-MPLS path is broken, should a node rather drop the 
>> packet, or forward it?
>> 
>> This can happen whenever the IGP points to a certain next hop, but 
>> that neither supplies a valid SID, nor allows LDP-stitching for 
>> whatever reason. For PUSH as well as for CONTINUE.
> 
> Speaking as an individual contributor, my reading of RFC 8660 (SR-MPLS) is that the packet is dropped ("Otherwise, drop the packet").
> https://clicktime.symantec.com/3Ac6NfmLToD6pwruqraPjMn6H2?u=https%3A%2
> F%2Fwww.rfc-editor.org%2Frfc%2Frfc8660.html%23name-forwarding-for-push
> -and-con
> 
> However that could be seen as a local behavior, hence possibly configurable.
> 
> As a network operator,
> - I understand your use case.
> - I equally understand the use case of someone preferring/requiring the packet to be dropped, e.g. in the VPN case where the isolation is the main requirement.
> 
> Best regards,
> --Bruno
> 
> 
>> We have been using MPLS transport and a BGP free core since about two 
>> decades now, using LDP. In the analog case, LDP creates "unlabelled"
>> entries in the LFIB, does the equivalent of a POP operation and 
>> forwards the packet to the next-hop as chosen by the IGP.
>> 
>> This behavior obviously breaks any traffic that relies on a service 
>> label, but it can protect some traffic.
>> In our case a huge percentage of all traffic still is public IPv4. 
>> This needs MPLS only for a transport label, be it LDP or SR-MPLS. If 
>> this traffic gets forwarded unlabelled, it follows an IGP default 
>> route to a central device, where it is 1) redirected to the correct 
>> destination and
>> 2) counted in a way that operators can quickly see whether and where 
>> this kind of failure occurs at some point in the network.
>> 
>> After more operational experience and several internal discussions we 
>> agreed that we want packets to be forwarded unlabelled rather than 
>> dropped. Anyone to share, or oppose this position?
>> 
>> Best regards, Martin
>> 
>> 
>>> Am 31.01.20 um 16:50 schrieb Martin Horneffer:
>>> Hello everyone,
>>> 
>>> again it seems the interesting questions only show up when applying 
>>> something to the live network...
>>> 
>>> We ran into something that poses a question related to RFC8660: What 
>>> is the exact meaning of section 2.10.1, "Forwarding for PUSH and 
>>> CONTINUE of Global SIDs", when the chosen neighbor doesn't provide a 
>>> valid MPLS path?
>>> 
>>> The relevant sections reads:
>>> 
>>>       -  Else, if there are other usable next hops, use them to forward
>>>          the incoming packet.  The method by which the router "R0"
>>>          decides on the possibility of using other next hops is beyond
>>>          the scope of this document.  For example, the MCC on "R0" may
>>>          chose the send an IPv4 packet without pushing any label to
>>>          another next hop.
>>> 
>>> Does the part "send an IPv4 packet without pushing any label" apply 
>>> to PUSH and CONTINUE, or just to PUSH?
>>> Does R0 have to validate that neighbor N can correctly process to 
>>> packet? Or can it forward the packet regardless?
>>> 
>>> The reason for asking is that we are now seeing issues similar to 
>>> ones we had when starting with LDP based MPLS about two decades ago:
>>> traffic being black holed even though a path to the destination 
>>> exists, because the MPLS path is interrupted somewhere in the middle.
>>> 
>>> With LDP we know the case of LFIBentries called "unlabelled". While 
>>> this does break connectivity for many kinds of service, e.g. those 
>>> relying on an additional service labels, it still works for plain
>>> IP(v4) traffic. In our cases, this works perfectly fine for all 
>>> internal routing and control traffic. And even for IPv4 traffic that 
>>> gets collected by a central router that injects a default route.
>>> 
>>> However, depending on the exact interpretation of the above 
>>> paragraph, an implementor might feel obliged to chose the next paragraph:
>>> 
>>>       -  Otherwise, drop the packet.
>>> 
>>> Which is, at least in our case, very unfortunate...
>>> 
>>> Any advice or opinion appreciated!
>>> 
>>> 
>>> Best regards, Martin
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> spring mailing list
>>> [e-mail]
>>> https://clicktime.symantec.com/3Upp6EVdxhZf2uCjs3V6nAi6H2?u=https%3A
>>> %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>> 
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://clicktime.symantec.com/3Upp6EVdxhZf2uCjs3V6nAi6H2?u=https%3A%
>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://clicktime.symantec.com/3Upp6EVdxhZf2uCjs3V6nAi6H2?u=https%3A%2
> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

_______________________________________________
spring mailing list
[e-mail]
https://clicktime.symantec.com/3Upp6EVdxhZf2uCjs3V6nAi6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring


-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. 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.
-----------------------------------------------------------------------------------------------------------------------