Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Les,
I am fine with the revised text and addresses my concern.
Rgds
Shraddha
Juniper Business Use Only
From: Les Ginsberg (ginsberg)
Sent: Tuesday, July 19, 2022 2:15 AM
To: Shraddha Hegde ; Les Ginsberg (ginsberg)
; lsr@ietf.org
Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
[External Email. Be cautious of content]
Shraddha -
Please see {LES2:] inline.
> -Original Message-
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
> Shraddha Hegde
> Sent: Monday, July 18, 2022 2:16 AM
> To: Les Ginsberg (ginsberg)
> mailto:ginsberg=40cisco@dmarc.ietf.org>>;
> lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-
> 01.txt
>
> Les,
>
> Pls see inline [SH2]
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Les Ginsberg (ginsberg)
> mailto:ginsberg=40cisco@dmarc.ietf.org>>
> Sent: Friday, July 15, 2022 10:21 PM
> To: Shraddha Hegde mailto:shrad...@juniper.net>>;
> Shraddha Hegde
> mailto:shrad...@juniper.net>>;
> lsr@ietf.org
> Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
>
> [External Email. Be cautious of content]
>
>
> Shraddha -
>
> Top posting since there now seems to be only one open issue.
>
>
> > [LES:] When Legacy routers are present, advertising different values
> > for link attributes in ASLA advertisements is an implementation bug.
> > That is clear from the previous statement in the same paragraph:
> >
> > "... routers that do not support the extensions defined in this
> > document will send and receive only legacy link attribute advertisements."
> >
> > This statement says routers that are legacy will send and receive
> > legacy advertisement which is obvious. It does not say other routers
> > which are ASLA capable MUST NOT send ASLA with application bit set
> > having different values In the presence of legacy routers in the domain.
[LES2:] I am struggling a bit with your concern because it suggests that you
think someone reading the RFC might think it is OK to send two different
advertisements for a given application/link/attribute. Such advertisements
could be both legacy, both ASLA, or a mixture. Frankly, this interpretation
never occurred to me - in large part because it seems obvious this would be
ambiguous and cause operational problems - but also because such a thing is not
discussed at all in existing specifications (such as RFC 5305) and this has
never been a concern.
Nevertheless, clarity is a good thing. Here is a proposed rewording of the
first part of Section 6.3.3:
Current Text:
For the applications defined in this document, routers that do not support the
extensions defined in this document will send and receive only legacy link
attribute advertisements. So long as there is any legacy router in the network
that has any of the applications enabled, all routers MUST continue to
advertise link attributes using legacy advertisements. In addition, the link
attribute values associated with the set of applications supported by legacy
routers (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy routers
have no way of advertising or processing application-specific values. Once all
legacy routers have been upgraded, migration from legacy advertisements to ASLA
advertisements can be achieved via the following steps:
Proposed Revised Text:
For the applications defined in this document, routers that do not support the
extensions defined in this document will send and receive only legacy link
attribute advertisements. In addition, the link attribute values associated
with the set of applications supported by legacy routers (RSVP-TE, SR Policy,
and/or LFA) are always shared since legacy routers have no way of advertising
or processing application-specific values. So long as there is any legacy
router in the network that has any of the applications defined in this document
enabled, all routers MUST continue to advertise link attributes for these
applications using only legacy advertisements. ASLA advertisements for these
applications MUST NOT be sent. Once all legacy routers have been upgraded,
migration from legacy advertisements to ASLA advertisements can be achieved via
the following steps:
> >
> > Implementations which deviate from this haven't done adequate testing
> > of their product before shipping it.
> > The scope of the discussion here is to get the specification
> > clear and unambiguous.
>
>
> Taking individual sentences out of context from Section 6.3.3 prolongs this
> discussion and leads to erroneous conclusions.
> The section says:
>
>
> 6.3.3. Interoperability with Legacy Routers
>
>For the applications defined in this document, routers that do not
>support the extensions defined in this document will send and receive
>only legacy link attr
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Shraddha -
Please see {LES2:] inline.
> -Original Message-
> From: Lsr On Behalf Of Shraddha Hegde
> Sent: Monday, July 18, 2022 2:16 AM
> To: Les Ginsberg (ginsberg) ;
> lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-
> 01.txt
>
> Les,
>
> Pls see inline [SH2]
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Les Ginsberg (ginsberg)
> mailto:ginsberg=40cisco@dmarc.ietf.org>>
> Sent: Friday, July 15, 2022 10:21 PM
> To: Shraddha Hegde mailto:shrad...@juniper.net>>;
> Shraddha Hegde
> mailto:shrad...@juniper.net>>;
> lsr@ietf.org
> Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
>
> [External Email. Be cautious of content]
>
>
> Shraddha -
>
> Top posting since there now seems to be only one open issue.
>
>
> > [LES:] When Legacy routers are present, advertising different values
> > for link attributes in ASLA advertisements is an implementation bug.
> > That is clear from the previous statement in the same paragraph:
> >
> > "... routers that do not support the extensions defined in this
> > document will send and receive only legacy link attribute advertisements."
> >
> > This statement says routers that are legacy will send and receive
> > legacy advertisement which is obvious. It does not say other routers
> > which are ASLA capable MUST NOT send ASLA with application bit set
> > having different values In the presence of legacy routers in the domain.
[LES2:] I am struggling a bit with your concern because it suggests that you
think someone reading the RFC might think it is OK to send two different
advertisements for a given application/link/attribute. Such advertisements
could be both legacy, both ASLA, or a mixture. Frankly, this interpretation
never occurred to me - in large part because it seems obvious this would be
ambiguous and cause operational problems - but also because such a thing is not
discussed at all in existing specifications (such as RFC 5305) and this has
never been a concern.
Nevertheless, clarity is a good thing. Here is a proposed rewording of the
first part of Section 6.3.3:
Current Text:
For the applications defined in this document, routers that do not support the
extensions defined in this document will send and receive only legacy link
attribute advertisements. So long as there is any legacy router in the network
that has any of the applications enabled, all routers MUST continue to
advertise link attributes using legacy advertisements. In addition, the link
attribute values associated with the set of applications supported by legacy
routers (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy routers
have no way of advertising or processing application-specific values. Once all
legacy routers have been upgraded, migration from legacy advertisements to ASLA
advertisements can be achieved via the following steps:
Proposed Revised Text:
For the applications defined in this document, routers that do not support the
extensions defined in this document will send and receive only legacy link
attribute advertisements. In addition, the link attribute values associated
with the set of applications supported by legacy routers (RSVP-TE, SR Policy,
and/or LFA) are always shared since legacy routers have no way of advertising
or processing application-specific values. So long as there is any legacy
router in the network that has any of the applications defined in this document
enabled, all routers MUST continue to advertise link attributes for these
applications using only legacy advertisements. ASLA advertisements for these
applications MUST NOT be sent. Once all legacy routers have been upgraded,
migration from legacy advertisements to ASLA advertisements can be achieved via
the following steps:
> >
> > Implementations which deviate from this haven't done adequate testing
> > of their product before shipping it.
> > The scope of the discussion here is to get the specification
> > clear and unambiguous.
>
>
> Taking individual sentences out of context from Section 6.3.3 prolongs this
> discussion and leads to erroneous conclusions.
> The section says:
>
>
> 6.3.3. Interoperability with Legacy Routers
>
>For the applications defined in this document, routers that do not
>support the extensions defined in this document will send and receive
>only legacy link attribute advertisements. So long as there is any
>legacy router in the network that has any of the applications
>enabled, all routers MUST continue to advertise link attributes using
>legacy advertisements.
>
>
> There is only one way to indicate - using ASLA - that legacy advertisements
> are to be used - which is to use the L-flag as defined in Section 4.2 - which
> states (in part):
>
> [SH2] The statement you make above is not clea
Re: [Lsr] Draft LSR agenda uploaded
Hi, Considering there are quite a few requests that didn't make the agenda, the chairs are planning to have an interim after IETF 114, targeting early September. The agenda has been updated. Please let us know if you have any questions or concerns. Thanks, Yingzhen On Wed, Jul 13, 2022 at 8:56 PM Yingzhen Qu wrote: > Hi, > > The draft agenda has been uploaded: > https://datatracker.ietf.org/meeting/114/session/lsr > > We have received more requests than we can fit into a 2-hour session. The > chairs are considering an LSR interim meeting for draft that didn’t make > the agenda. Meanwhile please socialize your draft one the list. > > If you’re on the agenda, please email your slides to lsr-cha...@ietf.org. > > Thanks, > Yingzhen > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] UPA/PUA
Hi Greg, That in fact even further highlights the benefits of using app to app > network quality detection. When app has been exposed with more then one > network path. > GIM>> I imagine that application layer OAM would be more burdensome than OAM in the underlay. Of course, the detection of some failures in an application is based on the application mechanism, not on the OAM. I consider that as a tradeoff. There is one more (IMHO very important) consideration to this. With respect to application detection if you run 1000 application instances each one of them needs to detect it. And not all of them may be sending packets with OAM all the time. So when I was going with ABR to PE probing that it should be enough for one application to detect the failure, ABR would intercept this and trigger UPA for all PEs which host behind 999 application endpoints. That way the vast majority of applications would not even notice the issue which is what we are all aiming for (one could hope :). Many thx, R. On Mon, Jul 18, 2022 at 3:40 PM Greg Mirsky wrote: > Hi Robert, > a note on active OAM in-lined below under GIM>>. > > Regards, > Greg > > On Sun, Jul 17, 2022 at 11:12 PM Robert Raszuk wrote: > >> Good point ! >> >> That proves that if PE-PE OAM does not follow app to app path it is >> useless. I would tend to agree. >> > GIM>> I agree, and the requirement for the active OAM to follow the same > path has always been placed at the front of all OAM requirement documents I > am familiar with. That equally applies to Fault Management (echo > request/reply or BFD) and Performance Monitoring OAM protocols. I think > that that requirement can be addressed by using the same encapsulation in > the underlay network. > >> >> That in fact even further highlights the benefits of using app to app >> network quality detection. When app has been exposed with more then one >> network path. >> > GIM>> I imagine that application layer OAM would be more burdensome than > OAM in the underlay. Of course, the detection of some failures in an > application is based on the application mechanism, not on the OAM. I > consider that as a tradeoff. > >> >> Thx, >> R. >> >> >> On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang >> wrote: >> >>> Hi, Greg: >>> >>> >>> >>> As indicated in the update draft >>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10 >>> >>> >>> >>> The motivation behind this draft is for either MPLS LPM FEC binding, >>> >>>SRv6 etc. tunnel ,or BGP overlay service that are using LPM >>> >>>forwarding plane where the IGP domain has been carved up into OSPF >>> >>>areas or IS-IS levels and summarization is utilized. In such >>> >>>scenario, a link or node failure can result in a black hole of >>> >>>traffic when the summary advertisement that covers the failure >>> >>>prefixes still exists. >>> >>> >>> >>>PUAM can track the unreachability of the important component >>> >>>prefixes to ensure traffic is not black hole sink routed for the >>> >>>above overlay services. >>> >>> >>> >>> Then considering only the BFD sessions among PEs are not enough, even we >>> put aside the BFD sessions overhead on each PE. >>> >>> >>> >>> >>> >>> Best Regards >>> >>> >>> >>> Aijun Wang >>> >>> China Telecom >>> >>> >>> >>> *From:* Greg Mirsky >>> *Sent:* Monday, July 18, 2022 11:06 AM >>> *To:* Aijun Wang >>> *Cc:* Robert Raszuk ; Christian Hopps < >>> cho...@chopps.org>; Peter Psenak ; lsr >>> *Subject:* Re: [Lsr] UPA/PUA >>> >>> >>> >>> Hi Aijun, >>> >>> I cannot figure out how you draw such a conclusion from my comments to >>> Robert. You may recall that from very early in the discussion, I was not >>> enthusiastic, to put it lightly, about either of the solutions. Instead, I >>> believe that multi-hop BFD should be used to monitor the continuity of a >>> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my >>> position clear. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang >>> wrote: >>> >>> Then considering both the scalability and possible false negative of BFD >>> based solution, can we say that the PUA/UPA solution is more preferable? >>> >>> >>> >>> Best Regards >>> >>> >>> >>> Aijun Wang >>> >>> China Telecom >>> >>> >>> >>> *From:* lsr-boun...@ietf.org *On Behalf Of *Greg >>> Mirsky >>> *Sent:* Monday, July 18, 2022 8:39 AM >>> *To:* Robert Raszuk >>> *Cc:* Christian Hopps ; Peter Psenak < >>> ppse...@cisco.com>; lsr >>> *Subject:* Re: [Lsr] UPA >>> >>> >>> >>> Hi Robert, >>> >>> top-posting and then my notes in-line under the GIM>> tag: >>> >>> As mentioned it is still not the same. BFDs on the link tell me that >>> link is up and part of the line card responder to BFD is alive. >>> >>> GIM>> I assume you refer to BFD single-hop. Then I have a question What >>> do you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in >>> the Down state may not indicate that the link i
Re: [Lsr] UPA/PUA
Hi Robert, a note on active OAM in-lined below under GIM>>. Regards, Greg On Sun, Jul 17, 2022 at 11:12 PM Robert Raszuk wrote: > Good point ! > > That proves that if PE-PE OAM does not follow app to app path it is > useless. I would tend to agree. > GIM>> I agree, and the requirement for the active OAM to follow the same path has always been placed at the front of all OAM requirement documents I am familiar with. That equally applies to Fault Management (echo request/reply or BFD) and Performance Monitoring OAM protocols. I think that that requirement can be addressed by using the same encapsulation in the underlay network. > > That in fact even further highlights the benefits of using app to app > network quality detection. When app has been exposed with more then one > network path. > GIM>> I imagine that application layer OAM would be more burdensome than OAM in the underlay. Of course, the detection of some failures in an application is based on the application mechanism, not on the OAM. I consider that as a tradeoff. > > Thx, > R. > > > On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang > wrote: > >> Hi, Greg: >> >> >> >> As indicated in the update draft >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10 >> >> >> >> The motivation behind this draft is for either MPLS LPM FEC binding, >> >>SRv6 etc. tunnel ,or BGP overlay service that are using LPM >> >>forwarding plane where the IGP domain has been carved up into OSPF >> >>areas or IS-IS levels and summarization is utilized. In such >> >>scenario, a link or node failure can result in a black hole of >> >>traffic when the summary advertisement that covers the failure >> >>prefixes still exists. >> >> >> >>PUAM can track the unreachability of the important component >> >>prefixes to ensure traffic is not black hole sink routed for the >> >>above overlay services. >> >> >> >> Then considering only the BFD sessions among PEs are not enough, even we >> put aside the BFD sessions overhead on each PE. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* Greg Mirsky >> *Sent:* Monday, July 18, 2022 11:06 AM >> *To:* Aijun Wang >> *Cc:* Robert Raszuk ; Christian Hopps < >> cho...@chopps.org>; Peter Psenak ; lsr >> *Subject:* Re: [Lsr] UPA/PUA >> >> >> >> Hi Aijun, >> >> I cannot figure out how you draw such a conclusion from my comments to >> Robert. You may recall that from very early in the discussion, I was not >> enthusiastic, to put it lightly, about either of the solutions. Instead, I >> believe that multi-hop BFD should be used to monitor the continuity of a >> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my >> position clear. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang >> wrote: >> >> Then considering both the scalability and possible false negative of BFD >> based solution, can we say that the PUA/UPA solution is more preferable? >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* lsr-boun...@ietf.org *On Behalf Of *Greg >> Mirsky >> *Sent:* Monday, July 18, 2022 8:39 AM >> *To:* Robert Raszuk >> *Cc:* Christian Hopps ; Peter Psenak < >> ppse...@cisco.com>; lsr >> *Subject:* Re: [Lsr] UPA >> >> >> >> Hi Robert, >> >> top-posting and then my notes in-line under the GIM>> tag: >> >> As mentioned it is still not the same. BFDs on the link tell me that link >> is up and part of the line card responder to BFD is alive. >> >> GIM>> I assume you refer to BFD single-hop. Then I have a question What >> do you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in >> the Down state may not indicate that the link is down but that the remote >> peer is operating down. >> >> >> >> Multihop BFD sessions will tell me that PE is up or down and that at >> least one connection to it is still up. That is subtle but there is an >> important difference. >> >> GIM>> Not necessarily, depends on the implementation. I can imagine a >> scenario, depending on the Detect Multiplier and Transmission Interval >> values, when the BFD multi-hop session going down indicates that the >> particular path to the remote PE lost continuity. >> >> >> >> And I repeat from the Abstract of RFC 5880: >> >>This document describes a protocol intended to detect faults in the >> >>bidirectional path between two forwarding engines, including >> >>interfaces, data link(s), and to the extent possible the forwarding >> >>engines themselves, with potentially very low latency. >> >> I believe that BFD cannot give us a reliable indication of the >> operational state of a node that hosts the BFD session, applications, and >> protocols hosted on that node. >> >> >> >> Regards, >> >> Greg >> >> >> >> >> >> On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk wrote: >> >> Hi Christian, >> >> >> >> > It seems you saying use multi-hop BFD for fast detection b/c yo
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Les, Pls see inline [SH2] Juniper Business Use Only -Original Message- From: Les Ginsberg (ginsberg) Sent: Friday, July 15, 2022 10:21 PM To: Shraddha Hegde ; Shraddha Hegde ; lsr@ietf.org Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt [External Email. Be cautious of content] Shraddha - Top posting since there now seems to be only one open issue. > [LES:] When Legacy routers are present, advertising different values > for link attributes in ASLA advertisements is an implementation bug. > That is clear from the previous statement in the same paragraph: > > "... routers that do not support the extensions defined in this > document will send and receive only legacy link attribute advertisements." > > This statement says routers that are legacy will send and receive > legacy advertisement which is obvious. It does not say other routers > which are ASLA capable MUST NOT send ASLA with application bit set > having different values In the presence of legacy routers in the domain. > > Implementations which deviate from this haven't done adequate testing > of their product before shipping it. > The scope of the discussion here is to get the specification > clear and unambiguous. Taking individual sentences out of context from Section 6.3.3 prolongs this discussion and leads to erroneous conclusions. The section says: 6.3.3. Interoperability with Legacy Routers For the applications defined in this document, routers that do not support the extensions defined in this document will send and receive only legacy link attribute advertisements. So long as there is any legacy router in the network that has any of the applications enabled, all routers MUST continue to advertise link attributes using legacy advertisements. There is only one way to indicate - using ASLA - that legacy advertisements are to be used - which is to use the L-flag as defined in Section 4.2 - which states (in part): [SH2] The statement you make above is not clear from the draft. Its very much valid to advertise attributes in TLV 22 and advertise ASLA with some application bit set as long as that application has been upgraded to support ASLA in entire network. Suggest below change " all routers MUST continue to advertise link attributes using legacy advertisements . If ASLA is advertised with legacy application bit set then L-bit MUST be set for that application" When the L-flag is set in the Application Identifier Bit Mask, all of the applications specified in the bit mask MUST use the legacy advertisements for the corresponding link found in TLVs Advertising Neighbor Information. Link attribute sub-sub-TLVs for the corresponding link attributes MUST NOT be advertised for the set of applications specified in the Standard or User-Defined Application Identifier Bit Masks, and all such sub-sub-TLVs MUST be ignored on receipt. Taking all of the above text into account, this means that for a given application: 1)In the presence of legacy routers legacy advertisements MUST be used 2)ASLA link attribute sub-sub-TLVs for that application MUST NOT be advertised 3)If ASLA link attribute sub-sub-TLVs are advertised they MUST be ignored So in the presence of legacy routers there is no possibility that a conforming implementation will use link attribute values that differ from the legacy values even if they were to be advertised (which in itself is forbidden). This seems to me to cover the issue you raise very clearly. Ay additional statement would be redundant. Les > -Original Message- > From: Shraddha Hegde > Sent: Friday, July 15, 2022 9:20 AM > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > ; lsr@ietf.org > Subject: RE: New Version Notification for > draft-ginsberg-lsr-rfc8919bis-01.txt > > Les, > > Pls see inline... > > > Juniper Business Use Only > > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Friday, July 15, 2022 9:11 PM > To: Shraddha Hegde ; Shraddha > Hegde ; lsr@ietf.org > Subject: RE: New Version Notification for > draft-ginsberg-lsr-rfc8919bis-01.txt > > [External Email. Be cautious of content] > > > Shraddha - > > Please see inline. > > > -Original Message- > > From: Shraddha Hegde > > Sent: Friday, July 15, 2022 5:43 AM > > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > > ; lsr@ietf.org > > Subject: RE: New Version Notification for > > draft-ginsberg-lsr-rfc8919bis-01.txt > > > > Les, > > > > Thanks for the reply. Pls see inline.. > > > > > > > > > > > > Juniper Business Use Only > > > > -Original Message- > > From: Lsr On Behalf Of Les Ginsberg > > (ginsberg) > > Sent: Thursday, July 14, 2022 2:32 AM > > To: Shraddha Hegde ; > > lsr@ietf.org > > Subject: Re: [Lsr] New Version Notification for > > draft-ginsberg-lsr-rfc8919bis- 01.txt > > > > [External Email. Be cautious of content] > > > > > > Shraddha - > > > > Thanx for your review and comments
