Hi again. I'm not sure what you are trying to prove (and unclear whether debating a draft that has IETF consensus on the wrong mailing list will solve anything).
If you are saying "What happens if an MPLS label gets corrupted in an in-flight packet?" then, yes, packets can be misdelivered." Remind me what happens if an IP address gets corrupted in an in-flight IP packet? Is here such a thing as an MPLS ACL? Well, yes and no. A router will not process a packet that caries a label that is not in its LFIB. LFIB entries can be set up per interface. Adrian -----Original Message----- From: Xiejingrong <xiejingr...@huawei.com> Sent: 15 April 2019 15:16 To: adr...@olddog.co.uk; bruno.decra...@orange.com Cc: lsr@ietf.org Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap Hi Adrian, thanks for the remind. I think the use case illustrated in the two diagrams is more attractive and easy to understand. I feel that, the use of dynamic tunnel inside an IGP will cause some other security concerns, as the RFC7510 said: "Corruption of that label could leak traffic across VPN boundaries......." A router advertise a tunnel-attribute like udp-tunnel-end-attribute to allow MPLS packets run over, then an unwanted IP packet may send to this tunnel-end IP/UDP, and the router can't filter the packet by MPLS label stack (is there MPLS ACL?). Thanks Jingrong -----Original Message----- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Monday, April 15, 2019 9:46 PM To: Xiejingrong <xiejingr...@huawei.com>; bruno.decra...@orange.com Cc: lsr@ietf.org Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap Wrong list for this discussion, Jingrong. Wrong draft to anchor this discussion to π But anyway, I think you need to read the whole of draft-ietf-mpls-sr-over-ip carefully to see its scope, how it does not compete with SRv6, and how it provides a handy migration strategy. Thanks, Adrian -----Original Message----- From: Xiejingrong <xiejingr...@huawei.com> Sent: 15 April 2019 14:34 To: adr...@olddog.co.uk; bruno.decra...@orange.com Cc: lsr@ietf.org Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap Hi Adrian, Is the intra-AS SR over IP really a key use case for draft-ietf-mpls-sr-over-ip ? I saw it says for this use case: "Tunneling MPLS into IP provides a technology that enables SR in an IPv4 and/or IPv6 network where the routers do not support SRv6 capabilities ..." SRv6 may have easier tunneling method, and SR-MPLS may not want to add another 'tunneling' within an IGP network. Would this draft-ietf-mpls-sr-over-ip be processed better focusing on the clear use case 'Tunnel Between SR-MPLS Sites', but without the dependency of the heavy IGP extension to support the intra-AS deployment of uncertain usecase/cost/tradeoff/.... ? Thanks Jingrong -----Original Message----- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, April 15, 2019 9:05 PM To: bruno.decra...@orange.com Cc: lsr@ietf.org Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap Nice response, Bruno. Thanks. Adrian -----Original Message----- From: bruno.decra...@orange.com <bruno.decra...@orange.com> Sent: 15 April 2019 10:47 To: adr...@olddog.co.uk Cc: lsr@ietf.org Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap Hi Adrian, > On the other hand, > https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ > found its way onto the RFC Editor Queue at around the same date and > has languished > there ever since. The OSPF document progressed well. The decision was made to normatively reference the IDR document for some codepoints, mostly because the IDR document was pre-dating. But then IDR document did not progress that fast and hence the OSPF document is in RFC editor queue waiting for the normative reference (for 538 days i.e. 1,5 years and counting). > https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ > shows expired in October 2017, The OSPF document had been significantly updated/rewritten toward the end which required some significant work. Since there were less traction with the IS-IS counterpart, to be honest I did not feel motivated to do the equivalent work for the IS-IS draft. If there is an interest for the IS-IS draft, we can revive and update it. OTOH, I'd rather avoid doing the work just to see the WG not progressing it to IESG during last call I assume (1) that your interest is coming from the IESG review on draft-ietf-mpls-sr-over-ip. draft-ietf-mpls-sr-over-ip is built over the IGP use case and hence relies on IGP advertising the encapsulation capability. Hence the normative reference, hence the fear the document would stay in the RFC editor queue for some time/ever. I think that this process question is mostly for the IESG. Personally I feel that a pragmatic approach would be to keep OSPF as a normative reference and downgrade IS-IS as informative. That may seem like a strange difference of treatment but the alternative is likely to just "silently" remove the IS-IS reference which would be an even bigger different of treatment. Regards, Bruno (1) Actually, your PS made it clear. PS: > Any clues? Thanks for not asking for the solution. That makes me feel more useful, for the same amount of work ;-) -----Original Message----- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Saturday, April 13, 2019 5:59 PM To: lsr@ietf.org Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap Hi, Any clues? https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ shows expired in October 2017, so I guess that is good and dead. On the other hand, https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found its way onto the RFC Editor Queue at around the same date and has languished there ever since. Did the ISIS work get replaced by some other draft without the "replaced by" link being set up? Was it deemed unnecessary in ISIS? Thanks, Adrian (who is trying to get draft-ietf-mpls-sr-over-ip through the IESG and finds a reference to this draft) -- Fairy tales from North Wales for adults of all ages https://www.feedaread.com/profiles/8604/ Available from your favourite online bookseller. Or contact me to receive a signed copy by mail. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ____________________________________________________________________________ _____________________________________________ 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. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
