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

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Thu, 16 January 2020 09:53 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 E8307120024; Thu, 16 Jan 2020 01:53:41 -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 nJH2xDAm2vip; Thu, 16 Jan 2020 01:53:37 -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 EF484120019; Thu, 16 Jan 2020 01:53:36 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5D47C33A885AF3EC9CF2; Thu, 16 Jan 2020 09:53:34 +0000 (GMT)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 16 Jan 2020 09:53:33 +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; Thu, 16 Jan 2020 17:53:31 +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; Thu, 16 Jan 2020 17:53:31 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>, Antoni Przygienda <prz@juniper.net>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
CC: BIER WG <bier@ietf.org>, Liangyanrong <liangyanrong@huawei.com>, dongjiajia <dongjiajia@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+AA==
Date: Thu, 16 Jan 2020 09:53:30 +0000
Message-ID: <6cd26cb68752405eab3c3ba0f769fe9e@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>
In-Reply-To: <MWHPR11MB16169BDE370EEA49036AAFD0C1370@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_6cd26cb68752405eab3c3ba0f769fe9ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/F7WsLo8oKJu-DIM3GWuAZanoV3s>
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: Thu, 16 Jan 2020 09:53:42 -0000

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>; Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>; Antoni Przygienda <prz@juniper.net>; aldrin.ietf@gmail.com; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: BIER WG <bier@ietf.org>; Liangyanrong <liangyanrong@huawei.com>; dongjiajia <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