Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Xiejingrong (Jingrong)]

support.

From:Christian Hopps 
To:lsr 
Cc:draft-li-lsr-ospfv3-srv6-extensions 
;lsr-ads 
;Christian Hopps ;Acee Lindem (acee) 

Date:2020-01-24 04:25:11
Subject:[Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/

Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & Acee.
___
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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Xiejingrong (Jingrong)]

support.

From:Christian Hopps 
To:lsr 
Cc:lsr-ads ;Christian Hopps ;Acee Lindem 
(acee) 
Date:2020-01-22 08:15:24
Subject:[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
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

Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the other

[Xiejingrong (Jingrong)]

Hi Les,
Thanks much for your patient answer.
I have no further questions since this has been noted in the list.

Best Regards,
Jingrong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 17, 2020 1:10 AM
To: Xiejingrong (Jingrong) ; Senthil Dhanaraj 

Cc: dongjiajia ; BIER WG ; Liangyanrong 
; lsr@ietf.org
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Jingrong –

Behavior of the N-flag is not BIER specific – so referencing RFC 8401 is not 
relevant here.

RFC 7794 clearly states that settings in Prefix Attributes sub-TLV take 
precedence over settings in Prefix-SID sub-TLV when both are present.
The use of source Router ID does not change depending on which of the other 
sub-TLVs are present/not present i.e., it is the only way of preserving the ID 
of the originator of the advertisement when the prefix is leaked into another 
level.

  Les

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Thursday, January 16, 2020 2:58 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>
Cc: dongjiajia mailto:dongjia...@huawei.com>>; BIER WG 
mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Hi
Sorry, I added the LSR but removed the question I was hesitating about. Take 
back now:
https://tools.ietf.org/html/rfc8667#section-2.1.1.2
   The N-Flag is used in order to define a Node-SID.  A router MAY set
   the N-Flag only if all of the following conditions are met:

  The prefix to which the Prefix-SID is attached is local to the
  router (i.e., the prefix is configured on one of the local
  interfaces, e.g., a 'stable transport' loopback).

  The prefix to which the Prefix-SID is attached has a Prefix length
  of either /32 (IPv4) or /128 (IPv6).

   The Prefix Attribute Flags sub-TLV 
[RFC7794<https://tools.ietf.org/html/rfc7794>] also defines the N-Flag
   and R-Flag and with the same semantics of the equivalent flags
   defined in this document.  Whenever the Prefix Attribute Flags sub-
   TLV is present for a given prefix, the values of the N-Flag and
   R-Flag advertised in that sub-TLV MUST be used, and the values in a
   corresponding Prefix-SID sub-TLV (if present) MUST be ignored.

So the question is that,
When RFC8667 is deployed without using the Prefix Attribute Flags sub-TLV 
[RFC7794], the N-flag in Prefix-SID sub-TLV[RFC8667] may work fine.
When RFC8667 is deployed with the 8401 and 7794, the N-flag in Prefix-SID 
sub-TLV[RFC8667] MUST be ignored, but the N-flag in Prefix Attribute Flags 
sub-TLV[RFC7794] may not provide the same value as Prefix-SID sub-TLV N-flag.
Then a the source Router ID sub-TLV have to be added in ?

Thanks
Jingrong


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, January 16, 2020 5:54 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: dongjiajia mailto:dongjia...@huawei.com>>; BIER WG 
mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the 
other

Hi Les,
Thanks for the clarification.
Would expect the Errata from Senthil as well.

Jingrong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 16, 2020 12:41 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; dongjiajia 
mailto:dongjia...@huawei.com>>
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Jingrong –

I had to look at this twice because of the long interval since the last email 
on this thread.
Inline.

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Tuesday, January 14, 2020 11:15 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; dongjiajia 
ma

Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the other

[Xiejingrong (Jingrong)]

Hi
Sorry, I added the LSR but removed the question I was hesitating about. Take 
back now:
https://tools.ietf.org/html/rfc8667#section-2.1.1.2
   The N-Flag is used in order to define a Node-SID.  A router MAY set
   the N-Flag only if all of the following conditions are met:

  The prefix to which the Prefix-SID is attached is local to the
  router (i.e., the prefix is configured on one of the local
  interfaces, e.g., a 'stable transport' loopback).

  The prefix to which the Prefix-SID is attached has a Prefix length
  of either /32 (IPv4) or /128 (IPv6).

   The Prefix Attribute Flags sub-TLV 
[RFC7794<https://tools.ietf.org/html/rfc7794>] also defines the N-Flag
   and R-Flag and with the same semantics of the equivalent flags
   defined in this document.  Whenever the Prefix Attribute Flags sub-
   TLV is present for a given prefix, the values of the N-Flag and
   R-Flag advertised in that sub-TLV MUST be used, and the values in a
   corresponding Prefix-SID sub-TLV (if present) MUST be ignored.

So the question is that,
When RFC8667 is deployed without using the Prefix Attribute Flags sub-TLV 
[RFC7794], the N-flag in Prefix-SID sub-TLV[RFC8667] may work fine.
When RFC8667 is deployed with the 8401 and 7794, the N-flag in Prefix-SID 
sub-TLV[RFC8667] MUST be ignored, but the N-flag in Prefix Attribute Flags 
sub-TLV[RFC7794] may not provide the same value as Prefix-SID sub-TLV N-flag.
Then a the source Router ID sub-TLV have to be added in ?

Thanks
Jingrong


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, January 16, 2020 5:54 PM
To: Les Ginsberg (ginsberg) ; Senthil Dhanaraj 
; Antoni Przygienda ; 
aldrin.i...@gmail.com; Jeffrey (Zhaohui) Zhang 
Cc: dongjiajia ; BIER WG ; Liangyanrong 
; lsr@ietf.org
Subject: Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the 
other

Hi Les,
Thanks for the clarification.
Would expect the Errata from Senthil as well.

Jingrong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 16, 2020 12:41 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; dongjiajia 
mailto:dongjia...@huawei.com>>
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Jingrong –

I had to look at this twice because of the long interval since the last email 
on this thread.
Inline.

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Tuesday, January 14, 2020 11:15 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; dongjiajia 
mailto:dongjia...@huawei.com>>
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Hi Les,
Thank you very much for the clarification.
I am curious if the text about N flag also need to change when BIER TLV is 
leaking from one level to another.
RFC7794 says in section 2.1 about N-flag: “Set when the prefix identifies the 
advertising router”.

[Les:] RFC7794 also says:

“The flag  MUST be preserved when leaked between levels.”

The identity of the originating router can be obtained from the source Router 
ID sub-TLV defined in https://tools.ietf.org/html/rfc7794#section-2.2

In the case when a BIER TLV (prefix=Prefix-ABR) is leaking by an ABR router 
from Level-1 to Level-2, the advertising router is ABR and the prefix is 
Prefix-ABR(a prefix bound to a Level-1 interface of ABR), so the N-flag need to 
be set.
In the case when a BIER TLV (prefix=Prefix-A) is leaking by an ABR router from 
Level-1  to Level-2, the advertising router is ABR but the prefix is Prefix-A(a 
prefix bound to a interface of router-A), so the N-flag need to be cleared.
Is the understanding correct ?
Would anyone please raise an Errata about this defect in the RFC ? I can also 
do that if needed.

[Les:] To be sure we are on the same page, the only Errata is the one mentioned 
below regarding the R flag. There is no issue regarding the N flag.
I believe Senthil indicated he would create an Errata for that but it appears 
that this never happened.

   Les

Best regards,
Jingrong

From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, April 13, 2019 4:24 AM
To: Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.ne

Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the other

[Xiejingrong (Jingrong)]

Hi
Sorry, I added the LSR but removed the question I was hesitating about. Take 
back now:
https://tools.ietf.org/html/rfc8667#section-2.1.1.2
   The N-Flag is used in order to define a Node-SID.  A router MAY set
   the N-Flag only if all of the following conditions are met:

  The prefix to which the Prefix-SID is attached is local to the
  router (i.e., the prefix is configured on one of the local
  interfaces, e.g., a 'stable transport' loopback).

  The prefix to which the Prefix-SID is attached has a Prefix length
  of either /32 (IPv4) or /128 (IPv6).

   The Prefix Attribute Flags sub-TLV 
[RFC7794<https://tools.ietf.org/html/rfc7794>] also defines the N-Flag
   and R-Flag and with the same semantics of the equivalent flags
   defined in this document.  Whenever the Prefix Attribute Flags sub-
   TLV is present for a given prefix, the values of the N-Flag and
   R-Flag advertised in that sub-TLV MUST be used, and the values in a
   corresponding Prefix-SID sub-TLV (if present) MUST be ignored.

So the question is that,
When RFC8667 is deployed without using the Prefix Attribute Flags sub-TLV 
[RFC7794], the N-flag in Prefix-SID sub-TLV[RFC8667] may work fine.
When RFC8667 is deployed with the 8401 and 7794, the N-flag in Prefix-SID 
sub-TLV[RFC8667] MUST be ignored, but the N-flag in Prefix Attribute Flags 
sub-TLV[RFC7794] may not provide the same value as Prefix-SID sub-TLV N-flag.
Then a the source Router ID sub-TLV have to be added in ?

Thanks
Jingrong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, January 16, 2020 5:54 PM
To: Les Ginsberg (ginsberg) ; Senthil Dhanaraj 
; Antoni Przygienda ; 
aldrin.i...@gmail.com; Jeffrey (Zhaohui) Zhang 
Cc: dongjiajia ; BIER WG ; Liangyanrong 
; lsr@ietf.org
Subject: Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the 
other

Hi Les,
Thanks for the clarification.
Would expect the Errata from Senthil as well.

Jingrong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 16, 2020 12:41 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; dongjiajia 
mailto:dongjia...@huawei.com>>
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Jingrong –

I had to look at this twice because of the long interval since the last email 
on this thread.
Inline.

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Tuesday, January 14, 2020 11:15 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; dongjiajia 
mailto:dongjia...@huawei.com>>
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Hi Les,
Thank you very much for the clarification.
I am curious if the text about N flag also need to change when BIER TLV is 
leaking from one level to another.
RFC7794 says in section 2.1 about N-flag: “Set when the prefix identifies the 
advertising router”.

[Les:] RFC7794 also says:

“The flag  MUST be preserved when leaked between levels.”

The identity of the originating router can be obtained from the source Router 
ID sub-TLV defined in https://tools.ietf.org/html/rfc7794#section-2.2

In the case when a BIER TLV (prefix=Prefix-ABR) is leaking by an ABR router 
from Level-1 to Level-2, the advertising router is ABR and the prefix is 
Prefix-ABR(a prefix bound to a Level-1 interface of ABR), so the N-flag need to 
be set.
In the case when a BIER TLV (prefix=Prefix-A) is leaking by an ABR router from 
Level-1  to Level-2, the advertising router is ABR but the prefix is Prefix-A(a 
prefix bound to a interface of router-A), so the N-flag need to be cleared.
Is the understanding correct ?
Would anyone please raise an Errata about this defect in the RFC ? I can also 
do that if needed.

[Les:] To be sure we are on the same page, the only Errata is the one mentioned 
below regarding the R flag. There is no issue regarding the N flag.
I believe Senthil indicated he would create an Errata for that but it appears 
that this never happened.

   Les

Best regards,
Jingrong

From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, April 13, 2019 4:24 AM
To: Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.ne

Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the other

[Xiejingrong (Jingrong)]

Hi Les,
Thanks for the clarification.
Would expect the Errata from Senthil as well.

Jingrong

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 16, 2020 12:41 AM
To: Xiejingrong (Jingrong) ; Senthil Dhanaraj 
; Antoni Przygienda ; 
aldrin.i...@gmail.com; Jeffrey (Zhaohui) Zhang 
Cc: BIER WG ; Liangyanrong ; dongjiajia 

Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Jingrong –

I had to look at this twice because of the long interval since the last email 
on this thread.
Inline.

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Tuesday, January 14, 2020 11:15 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>; Liangyanrong 
mailto:liangyanr...@huawei.com>>; dongjiajia 
mailto:dongjia...@huawei.com>>
Subject: RE: RFC8401 - Question on BIER TLV leaking from one level to the other

Hi Les,
Thank you very much for the clarification.
I am curious if the text about N flag also need to change when BIER TLV is 
leaking from one level to another.
RFC7794 says in section 2.1 about N-flag: “Set when the prefix identifies the 
advertising router”.

[Les:] RFC7794 also says:

“The flag  MUST be preserved when leaked between levels.”

The identity of the originating router can be obtained from the source Router 
ID sub-TLV defined in https://tools.ietf.org/html/rfc7794#section-2.2

In the case when a BIER TLV (prefix=Prefix-ABR) is leaking by an ABR router 
from Level-1 to Level-2, the advertising router is ABR and the prefix is 
Prefix-ABR(a prefix bound to a Level-1 interface of ABR), so the N-flag need to 
be set.
In the case when a BIER TLV (prefix=Prefix-A) is leaking by an ABR router from 
Level-1  to Level-2, the advertising router is ABR but the prefix is Prefix-A(a 
prefix bound to a interface of router-A), so the N-flag need to be cleared.
Is the understanding correct ?
Would anyone please raise an Errata about this defect in the RFC ? I can also 
do that if needed.

[Les:] To be sure we are on the same page, the only Errata is the one mentioned 
below regarding the R flag. There is no issue regarding the N flag.
I believe Senthil indicated he would create an Errata for that but it appears 
that this never happened.

   Les

Best regards,
Jingrong

From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, April 13, 2019 4:24 AM
To: Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>
Subject: Re: [Bier] RFC8401 - Question on BIER TLV leaking from one level to 
the other

Senthil –

There is no such thing as a “BIER-ISIS extension TLV”.
There is only the “BIER Info” sub-TLV(sic) which is carried in a Prefix 
Reachability TLV (one of TLVs 135, 235, 236, and 237).
Therefore the Prefix-Attribute sub-TLV can and should be present in such a TLV 
as well.

See https://tools.ietf.org/html/rfc8401#section-4.2

The only minor issue here is that the RFC says:

o  When the Prefix Attributes Flags sub-TLV [RFC7794] is present, the
  N flag MUST be set and the R flag MUST NOT be set.

In cases where the prefix is leaked the R flag will be set. The text is a 
holdover from early versions where we had prohibited leaking.
In cases where the prefix is leaked the R flag will be set.

I suppose this deserves an Errata.
I thought this issue had been discussed and addressed – but I couldn’t find any 
relevant email and clearly the published text has a flaw.
Sigh…

Les


From: Senthil Dhanaraj 
mailto:senthil.dhanaraj.i...@gmail.com>>
Sent: Thursday, April 11, 2019 11:03 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Antoni Przygienda mailto:p...@juniper.net>>; 
aldrin.i...@gmail.com<mailto:aldrin.i...@gmail.com>; Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>>
Cc: BIER WG mailto:b...@ietf.org>>
Subject: RFC8401 - Question on BIER TLV leaking from one level to the other

Hi Authors,

When ABR leaks the Prefix (& BIER TLVs) from one level to another, the LSP 
contains both the ABR's local prefix and the other prefix'es which are 
re-advertised from one level to the other.
Nodes receiving such an LSP should be able to identify the Prefix (& BIER TLV) 
that is originally local to the ABR from the other inter (re-advertised) 
prefix'es.

Unlike SR-ISIS extensions TLV, BIER-ISIS extension TLVs do not have N/R flags.

Hence the only way to identify the prefix type (local or re-advertised) is by 
having the ABR a

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Xiejingrong]

+1 support of the adoption and the name!

Jingrong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, August 14, 2019 4:18 AM
To: Les Ginsberg (ginsberg) ; Robert Raszuk 

Cc: lsr@ietf.org; Tony Li ; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

+1

Cheers,
Jeff
On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk 
mailto:rob...@raszuk.net>>, wrote:

> lsr-isis-extended-hierarchy

 Sounds great !

___
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

Re: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Xiejingrong]

Support adoption.

Jingrong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 09, 2019 9:50 PM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support 
Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

We been holding off WG adoption until the base SRv6 draft was adopted in 
SPRING. Now that 
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ 
has been adopted, we are starting a two week LSR WG adoption poll for the 
subject draft. Please register your support or objection prior to 12:00 AM UTC, 
on May 25th, 2019.

For your convenience, here is a URL for the draft:

https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/

Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Xiejingrong]

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 ; 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 
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 
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 E

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

[Xiejingrong]

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 
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