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

Reply via email to