Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 13 Apr 2019 16:59:05 +0100

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.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Sun, 14 Apr 2019 00:56:17 +0800

I will update the ISIS draft soon.

Xiaohu

来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：Adrian Farrel<[email-masked]>
日　期：2019年04月13日 23:59:05
收件人：<[email-masked]>
主　题：[Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

On the other hand,

Thanks,

_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 13 Apr 2019 18:09:28 +0100

Thanks Xiaohu,

That at least indicates that you would like to see an RFC published.

But I wonder whether the WG has given up on this work? Two years is a long time to make no advances and to have no demands for publication.

I wonder why no one has cared in the interim.

Best,

Adrian

From: 徐小虎(义先) <[email-masked]> 
Sent: 13 April 2019 17:56
To: [email-masked]; [email-masked]
Subject: 回复：[Lsr] Status of draft-ietf-isis-encapsulation-cap

Xiaohu

来自钉钉专属商务邮箱

------------------------------------------------------------------
发件人：Adrian Farrel<[email-masked] <mailto:[email-masked]> >
日　期：2019年04月13日 23:59:05
收件人：<[email-masked] <mailto:[email-masked]> >
主　题：[Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

On the other hand,

Thanks,

_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

---

From: Philip Christian <[email-masked]>
Date: Sat, 13 Apr 2019 18:17:12 +0100

For the record;

Also there is a an encapsulation capability TLV in ITU-T G.7712
here

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.7712-201009-I!!PDF-E&type=items

see appendix B.

also described here

https://tools.ietf.org/html/draft-ietf-isis-auto-encap-03

regards, Philip

On 13/04/2019 17:56, 徐小虎(义先) wrote:
> 来自钉钉专属商务邮箱 <(null)>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Mon, 15 Apr 2019 11:20:35 +0800

Both the OSPF and ISIS drafts have heavy dependency on the BGP counterpart (https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11) which has not been published yet since it was adopted almost 4 years ago.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Adrian Farrel <[email-masked]>
Send Time:2019年4月14日(星期日) 01:09
To:徐小虎(义先) <[email-masked]>; lsr <[email-masked]>
Subject:Re: [Lsr] 回复： Status of draft-ietf-isis-encapsulation-cap

Thanks Xiaohu,

Best,
Adrian

Xiaohu

来自钉钉专属商务邮箱

Hi,

Any clues?

On the other hand,

Thanks,

---

From: <[email-masked]>
Date: Mon, 15 Apr 2019 09:46:41 +0000

Hi Adrian,

> its way onto the RFC Editor Queue at around the same date and has languished

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.

> 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:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: [email-masked]
Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

On the other hand,

Thanks,

_________________________________________________________________________________________________________________________

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Apr 2019 14:05:11 +0100

Nice response, Bruno.
Thanks.
Adrian

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: 15 April 2019 10:47
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

> its way onto the RFC Editor Queue at around the same date and has
languished

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

> 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:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: [email-masked]
Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

On the other hand,

Thanks,

____________________________________________________________________________
_____________________________________________

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.

---

From: Xiejingrong <[email-masked]>
Date: Mon, 15 Apr 2019 13:33:44 +0000

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:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Nice response, Bruno.
Thanks.
Adrian

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: 15 April 2019 10:47
To: [email-masked]
Cc: [email-masked]
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

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

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: [email-masked]
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.

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.

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Apr 2019 14:46:10 +0100

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 <[email-masked]> 
Sent: 15 April 2019 14:34
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

Thanks
Jingrong

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Nice response, Bruno.
Thanks.
Adrian

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: 15 April 2019 10:47
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

languished

expired in October 2017,

Regards,

Bruno

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: [email-masked]
Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

On the other hand,

Thanks,

---

From: Xiejingrong <[email-masked]>
Date: Mon, 15 Apr 2019 14:16:09 +0000

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:[email-masked]] 
Sent: Monday, April 15, 2019 9:46 PM
To: Xiejingrong <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Thanks,
Adrian

-----Original Message-----
From: Xiejingrong <[email-masked]>
Sent: 15 April 2019 14:34
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

Thanks
Jingrong

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Nice response, Bruno.
Thanks.
Adrian

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: 15 April 2019 10:47
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

languished

expired in October 2017,

Regards,

Bruno

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: [email-masked]
Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

On the other hand,

Thanks,

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Apr 2019 15:31:19 +0100

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 <[email-masked]> 
Sent: 15 April 2019 15:16
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,
thanks for the remind.

Thanks
Jingrong

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Monday, April 15, 2019 9:46 PM
To: Xiejingrong <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Thanks,
Adrian

-----Original Message-----
From: Xiejingrong <[email-masked]>
Sent: 15 April 2019 14:34
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

Thanks
Jingrong

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Nice response, Bruno.
Thanks.
Adrian

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: 15 April 2019 10:47
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

languished

expired in October 2017,

Regards,

Bruno

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: [email-masked]
Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

On the other hand,

Thanks,