Peter,
Thank you for the explanation.
Linda
-----Original Message-----
From: Peter Psenak <ppse...@cisco.com>
Sent: Wednesday, June 10, 2020 3:40 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; Acee Lindem (acee)
<a...@cisco.com>; gen-art@ietf.org
Cc: last-c...@ietf.org; draft-ietf-ospf-te-link-attr-reuse....@ietf.org;
l...@ietf.org
Subject: Re: [Lsr] Genart last call review of
draft-ietf-ospf-te-link-attr-reuse-12
Linda,
On 09/06/2020 22:20, Linda Dunbar wrote:
> Peter,
>
> Thank you for the explanation.
>
> So you are saying that a node might not support RSVP or RSVP-TE, but can
> advertise the TE related attributes for SR purpose. When the head node
> receiving the advertisement also support RSVP-TE, it might use the
> information to establish the RSVP path, which will be rejected by the node
> that don't support RSVP but advertise the TE related information? is it
> correct?
yes.
>
> It would be useful if you can add a statement to explain the scenario that a
> node only has a subset of links supporting RSVP-TE but also capable of
> advertising TE related attributes for links that are not enabled for RSVP-TE.
There is a text in the draft:
An example where this ambiguity causes a problem is a network in
which RSVP-TE is enabled only on a subset of its links. A link
attribute is advertised for the purpose of another application (e.g.
SRTE) for a link that is not enabled for RSV-TE. As soon as the
router that is an RSVP-TE head-end sees the link attribute being
advertised for that link, it assumes RSVP-TE is enabled on that
link, even though it is not. If such RSVP-TE head-end router tries
to setup an RSVP-TE path via that link it will result in the path
setup failure.
thanks,
Peter
>
> Linda Dunbar
>
> -----Original Message-----
> From: Peter Psenak <ppse...@cisco.com>
> Sent: Tuesday, June 9, 2020 10:18 AM
> To: Linda Dunbar <linda.dun...@futurewei.com>; Acee Lindem (acee)
> <a...@cisco.com>; gen-art@ietf.org
> Cc: last-c...@ietf.org; l...@ietf.org;
> draft-ietf-ospf-te-link-attr-reuse....@ietf.org
> Subject: Re: Genart last call review of
> draft-ietf-ospf-te-link-attr-reuse-12
>
> Linda,
>
> On 09/06/2020 16:18, Linda Dunbar wrote:
>> Acee and Peter,
>>
>> Thank you very much for the explanation.
>>
>> My fundamental question is: What problem will be encountered when a node use
>> the TE information on links that RSVP-TE are not enabled?
>
> The problem is on a node where RSVP is enabled, when it receives the link
> attribute for a remote link where RSVP is not enabled.
>
> An example where this ambiguity causes a problem is a network in
> which RSVP-TE is enabled only on a subset of its links. A link
> attribute is advertised for the purpose of another application (e.g.
> SRTE) for a link that is not enabled for RSV-TE. As soon as the
> router that is an RSVP-TE head-end sees the link attribute being
> advertised for that link, it assumes RSVP-TE is enabled on that link,
> even though it is not. If such RSVP-TE head-end router tries to
> setup an RSVP-TE path via that link it will result in the path setup
> failure.
>
>>
>> I would think that the reason that RSVP-TE is enabled per interface is
>> because not every interface is capable of generating the TE information, or
>> the Node doesn't want to share the detailed TE information to remote nodes
>> (for security reasons?).
>
> the simplest reason is that RSVP is not used on the router at all.
>
>>
>> If SR is enabled on a node, which is capable of detecting the TE
>> information on the links to be advertised to remote nodes, what problems do
>> we have when the OSPF-TE application on remote nodes utilizes the Link TE
>> information?
>
> please see above.
>
> thanks,
> Peter
>>
>>
>> Thank you.
>>
>> Linda
>>
>> -----Original Message-----
>> From: Acee Lindem (acee) <a...@cisco.com>
>> Sent: Tuesday, June 9, 2020 6:25 AM
>> To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Linda Dunbar
>> <linda.dun...@futurewei.com>; gen-art@ietf.org
>> Cc: last-c...@ietf.org; l...@ietf.org;
>> draft-ietf-ospf-te-link-attr-reuse....@ietf.org
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>>
>> Hi Linda,
>> One more point...
>>
>> On 6/9/20, 4:52 AM, "Peter Psenak" <ppse...@cisco.com> wrote:
>>
>> Linda,
>>
>> On 09/06/2020 02:37, Linda Dunbar wrote:
>> > Peter,
>> >
>> > Thank you very much for adding the extra text to explain.
>> >
>> > But SR is supposed to be transparent to all intermediate nodes. Does
>> your draft require a node to be specifically configured for each link to
>> support or not support SR or RSVP-TE?
>>
>> the draft does not pose any new requirements in terms of how
>> applications are enabled.
>>
>> Please note that RSVP-TE is typically enabled per interface, SRTE is
>> typically enabled on a per node basis.
>>
>> For SR, these attributes are attributes are advertised in OSPF so that any
>> OSPF router or controller in the OSPF domain can make use of them to compute
>> the SR path.
>>
>> Thanks,
>> Acee
>>
>>
>> >
>> > In addition, there is no new attributes described in the document.
>> So if a node is advertising TE related attributes for a specific link, such
>> as bandwidth, delay, what kind problems this node will encounter if a
>> remote node utilize those TE specific attributes?
>>
>> the problem is when the link attributes advertise for the purpose of
>> application other than RSVP-TE is mistakenly used by RSVP-TE.
>>
>> thanks,
>> Peter
>>
>>
>>
>> >
>> > Linda Dunbar
>> >
>> > -----Original Message-----
>> > From: Peter Psenak <ppse...@cisco.com>
>> > Sent: Monday, June 1, 2020 11:01 AM
>> > To: Linda Dunbar <linda.dun...@futurewei.com>; gen-art@ietf.org
>> > Cc: last-c...@ietf.org; l...@ietf.org;
>> draft-ietf-ospf-te-link-attr-reuse....@ietf.org
>> > Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>> >
>> > Hi Linda,
>> >
>> >
>> > On 01/06/2020 17:30, Linda Dunbar wrote:
>> >> Peter,
>> >> You said:
>> >> /“//the problem with existing advertisement is that RSVP-TE will use
>> >> it, even if it was not intended to be used by RSVP-TE.//”/ What is
>> the
>> >> problem if RSVP-TE use the advertisement? What specific attributes
>> >> that RSVP-TE shouldn’t use?
>> >
>> > Following text has been added to the draft based on comments from
>> Scott.
>> >
>> > "An example where this ambiguity causes problem is a network which
>> has RSVP-TE enabled on one subset of links, and SRTE enabled on a different
>> subset. A link attribute is advertised for the purpose of some other
>> application (e.g. SRTE) for a link that is not enabled for RSV-TE. As soon
>> as the router that is an RSVP-TE head-end sees the link attribute being
>> advertised for such link, it assumes RSVP-TE is enabled on that link, even
>> though in reality, RSVP-TE is not enabled on it. If such RSVP-TE head-end
>> router tries to setup an RSVP-TE path via link where RSVP-TE is not enabled
>> it will result in the path setup failure."
>> >
>> > Hope it makes it clear and addresses your question.
>> >
>> > thanks,
>> > Peter
>> >
>> >
>> >
>> >
>> >
>> >> Linda Dunbar
>> >> -----Original Message-----
>> >> From: Peter Psenak <ppse...@cisco.com>
>> >> Sent: Friday, May 29, 2020 10:00 AM
>> >> To: Linda Dunbar <linda.dun...@futurewei.com>; gen-art@ietf.org
>> >> Cc: last-c...@ietf.org; l...@ietf.org;
>> >> draft-ietf-ospf-te-link-attr-reuse....@ietf.org
>> >> Subject: Re: Genart last call review of
>> >> draft-ietf-ospf-te-link-attr-reuse-12
>> >> Linda,
>> >> On 29/05/2020 16:52, Linda Dunbar wrote:
>> >>> Peter,
>> >>> You said:
>> >>> /we are not defining any new attributes./ /We are allowing an
>> >>> existing link attributes to be used by other applications,
>> including,
>> >>> but not limited to SRTE./ What prevent a node (or an application on
>> >>> the node) receiving the LSA from using the attributes carried by
>> the LSA?
>> >> the problem with existing advertisement is that RSVP-TE will use it,
>> >> even if it was not intended to be used by RSVP-TE.
>> >> We are providing a way to explicitly advertised apps that are
>> allowed
>> >> to use the advertised attributes.
>> >>> If no new attributes are
>> >>> to be added, then why need a new ASLA sub-TLV?
>> >> to be able to use the existing attributes for new apps, other than
>> RSVP-TE.
>> >> thanks,
>> >> Peter
>> >>> Linda
>> >>> -----Original Message-----
>> >>> From: Peter Psenak <ppse...@cisco.com <mailto:ppse...@cisco.com>>
>> >>> Sent: Friday, May 29, 2020 5:51 AM
>> >>> To: Linda Dunbar <linda.dun...@futurewei.com
>> >>> <mailto:linda.dun...@futurewei.com>>;
>> >> gen-art@ietf.org <mailto:gen-art@ietf.org>
>> >>> Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; l...@ietf.org
>> >> <mailto:l...@ietf.org>;
>> >>> draft-ietf-ospf-te-link-attr-reuse....@ietf.org
>> >> <mailto:draft-ietf-ospf-te-link-attr-reuse....@ietf.org>
>> >>> Subject: Re: Genart last call review of
>> >>> draft-ietf-ospf-te-link-attr-reuse-12
>> >>> Hi Linda,
>> >>> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
>> >>>> Reviewer: Linda Dunbar
>> >>>> Review result: Not Ready
>> >>>>
>> >>>> I am the assigned Gen-ART reviewer for this draft. The General
>> Area
>> >>>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by
>> >>>> the IESG for the IETF Chair. Please treat these comments just
>> like
>> >>>> any other last call comments.
>> >>>>
>> >>>> For more information, please see the FAQ at
>> >>>>
>> >>>>
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C15106e48f1084954b35a08d80d19ccee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637273751753415740&sdata=0aA%2B%2F9dM%2FxhneUaVnh435vqNVe6vLttlL8U8kGbTcMw%3D&reserved=0>.
>> >>>>
>> >>>> Document: draft-ietf-ospf-te-link-attr-reuse-??
>> >>>> Reviewer: Linda Dunbar
>> >>>> Review Date: 2020-05-28
>> >>>> IETF LC End Date: 2020-05-29
>> >>>> IESG Telechat date: Not scheduled for a telechat
>> >>>>
>> >>>> Summary: this document introduces a new link attribute
>> advertisement
>> >>>> in OSPFv2 and OSPFv3 to address general link properties needed for
>> >>>> new applications, such as Segment Routing.
>> >>>>
>> >>>> Major issues:
>> >>>> The document has good description on the TLV structure of the
>> >>>> Application specific Advertisements, but fails to describe what
>> are
>> >>>> the NEW Link attributes needed by Segment Routing. Page 7 (section
>> >>>> 5) has a really good description on all the link properties added
>> to
>> >>>> OSFP (RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can
>> see
>> >>>> Segment Routing would need each node to advertise its own SID and
>> >>>> the SIDs of adjacent nodes. Can't they be encoded (or extended)
>> in OSPF's NODE ID?
>> >>> we are not defining any new attributes.
>> >>> We are allowing an existing link attributes to be used by other
>> >>> applications, including, but not limited to SRTE.
>> >>> thanks,
>> >>> Peter
>> >>>>
>> >>>> Minor issues:
>> >>>>
>> >>>> Nits/editorial comments:
>> >>>>
>> >>>> Best regards,
>> >>>>
>> >>>> Linda Dunbar
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >
>> >
>> >
>>
>>
>>
>>
>
> _______________________________________________
> Lsr mailing list
> l...@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Clinda.dunbar%40
> futurewei.com%7C15106e48f1084954b35a08d80d19ccee%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C637273751753415740&sdata=6rcZuEZernpe88EGj
> ehGIesn7nPpAX6UdI2wPLFonZI%3D&reserved=0
>
>
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
