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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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) <[e-mail]>
Sent: Thursday, January 16, 2020 2:58 AM
To: Les Ginsberg (ginsberg) <[e-mail]>; Senthil Dhanaraj <[e-mail]>
Cc: dongjiajia <[e-mail]>; BIER WG <[e-mail]>; Liangyanrong <[e-mail]>; [e-mail]
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:[e-mail]] On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, January 16, 2020 5:54 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Senthil Dhanaraj <[e-mail]<mailto:[e-mail]>>; Antoni Przygienda <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: dongjiajia <[e-mail]<mailto:[e-mail]>>; BIER WG <[e-mail]<mailto:[e-mail]>>; Liangyanrong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Thursday, January 16, 2020 12:41 AM
To: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>; Senthil Dhanaraj <[e-mail]<mailto:[e-mail]>>; Antoni Przygienda <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>; Liangyanrong <[e-mail]<mailto:[e-mail]>>; dongjiajia <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 14, 2020 11:15 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Senthil Dhanaraj <[e-mail]<mailto:[e-mail]>>; Antoni Przygienda <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>; Liangyanrong <[e-mail]<mailto:[e-mail]>>; dongjiajia <[e-mail]<mailto:[e-mail]>>
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:[e-mail]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, April 13, 2019 4:24 AM
To: Senthil Dhanaraj <[e-mail]<mailto:[e-mail]>>; Antoni Przygienda <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 11, 2019 11:03 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Antoni Przygienda <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
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