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

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Fri, 17 January 2020 09:19 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6AE120236; Fri, 17 Jan 2020 01:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBxRwdDamedX; Fri, 17 Jan 2020 01:19:49 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24D81207FC; Fri, 17 Jan 2020 01:19:48 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2BF1CB6916D432C0BFF7; Fri, 17 Jan 2020 09:19:46 +0000 (GMT)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 17 Jan 2020 09:19:45 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 17 Jan 2020 17:19:42 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Fri, 17 Jan 2020 17:19:42 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>
CC: dongjiajia <dongjiajia@huawei.com>, BIER WG <bier@ietf.org>, Liangyanrong <liangyanrong@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: RFC8401 - Question on BIER TLV leaking from one level to the other
Thread-Index: AQHU8W22VuGKC2ubU0CKFoF/QhHX9Kfs/sHQgACheaCAAR6+AIAAFaNwgABl7iCAARBg8A==
Date: Fri, 17 Jan 2020 09:19:42 +0000
Message-ID: <ad38af3d42f24b259e400e711a596df5@huawei.com>
References: <CAG9=0b+Xhunb45=1mxfCS1preLWrWAj4YvCpqDv1L8b_Ai=G2w@mail.gmail.com> <BYAPR11MB3638B02015E08711E64A1470C1280@BYAPR11MB3638.namprd11.prod.outlook.com> <e671f824cbad4318a66cce00160917ce@huawei.com> <MWHPR11MB16169BDE370EEA49036AAFD0C1370@MWHPR11MB1616.namprd11.prod.outlook.com> <6cd26cb68752405eab3c3ba0f769fe9e@huawei.com> <1f05772ebdfc41d8ac5ee1bda159d518@huawei.com> <MWHPR11MB16161FD81E89FD1537C0025FC1360@MWHPR11MB1616.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB16161FD81E89FD1537C0025FC1360@MWHPR11MB1616.namprd11.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.118]
Content-Type: multipart/alternative; boundary="_000_ad38af3d42f24b259e400e711a596df5huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/tFyKG5HUVx-fEEs2k7fYhiii0m4>
Subject: Re: [Lsr] RFC8401 - Question on BIER TLV leaking from one level to the other
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 09:19:52 -0000

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:ginsberg@cisco.com]
Sent: Friday, January 17, 2020 1:10 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>; Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>
Cc: dongjiajia <dongjiajia@huawei.com>; BIER WG <bier@ietf.org>; Liangyanrong <liangyanrong@huawei.com>; 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) <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>
Sent: Thursday, January 16, 2020 2:58 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com<mailto:senthil.dhanaraj.ietf@gmail.com>>
Cc: dongjiajia <dongjiajia@huawei.com<mailto:dongjiajia@huawei.com>>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; Liangyanrong <liangyanrong@huawei.com<mailto:liangyanrong@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-bounces@ietf.org] On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, January 16, 2020 5:54 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com<mailto:senthil.dhanaraj.ietf@gmail.com>>; Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>; aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: dongjiajia <dongjiajia@huawei.com<mailto:dongjiajia@huawei.com>>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; Liangyanrong <liangyanrong@huawei.com<mailto:liangyanrong@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:ginsberg@cisco.com]
Sent: Thursday, January 16, 2020 12:41 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>; Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com<mailto:senthil.dhanaraj.ietf@gmail.com>>; Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>; aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; Liangyanrong <liangyanrong@huawei.com<mailto:liangyanrong@huawei.com>>; dongjiajia <dongjiajia@huawei.com<mailto:dongjiajia@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) <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>
Sent: Tuesday, January 14, 2020 11:15 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com<mailto:senthil.dhanaraj.ietf@gmail.com>>; Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>; aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; Liangyanrong <liangyanrong@huawei.com<mailto:liangyanrong@huawei.com>>; dongjiajia <dongjiajia@huawei.com<mailto:dongjiajia@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-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, April 13, 2019 4:24 AM
To: Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com<mailto:senthil.dhanaraj.ietf@gmail.com>>; Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>; aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BIER WG <bier@ietf.org<mailto:bier@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 <senthil.dhanaraj.ietf@gmail.com<mailto:senthil.dhanaraj.ietf@gmail.com>>
Sent: Thursday, April 11, 2019 11:03 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>; aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: BIER WG <bier@ietf.org<mailto:bier@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 advertise the "IPv4/IPv6 Extended Reachability Attribute Flags sub-TLV - RFC7794" whenever it leaks the BIER TLVs from one level to another. Is my understanding correct?

Ref from - RFC 7794 - 2.1<https://tools.ietf.org/html/rfc7794#section-2.1>. IPv4/IPv6 Extended Reachability Attribute Flags


       0 1 2 3 4 5 6 7...

      +-+-+-+-+-+-+-+-+...

      |X|R|N|          ...

      +-+-+-+-+-+-+-+-+...


   R-Flag:  Re-advertisement Flag (Bit 1)

      Set when the prefix has been leaked from one level to another

      (upwards or downwards).

Thanks,
Senthil