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?
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%7C34b141b11fe6484fc65208d803e0e851%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263611798933480&sdata=hXIX5xyAiXcFdymKVyg%2BVuQZAznQKJV5Il7U9OOdVv0%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
>>
>>
>>
>>
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
