Hi Rakesh, Thanks for adding the new reference to RFC7551 in the requirement we’re discussing. Please see below for replies
[acm] on this and other comments. Al From: Rakesh Gandhi [mailto:rgandhi.ietf@xxxxxxxxx]
Thank you Al for the review. Please see replies inline with <RG>... On Wed, Jan 27, 2021 at 6:23 PM Al Morton via Datatracker <noreply@xxxxxxxx> wrote:
<RG> How about following text? The Tunnel (as defined in [RFC3209]) containing the forward and reverse LSPs of the Single-sided Bidirectional LSP Association on the originating node MUST be the same [RFC7551], both LSPs albeit with with reverse
endpoint nodes. [acm]
Some relevant text from 7551 seems to be: 3.1.1.
Single-Sided Provisioning For the single-sided provisioning, the Traffic Engineering (TE) tunnel is configured only on one endpoint. An LSP for this tunnel is initiated by the initiating endpoint with the (Extended) ASSOCIATION and REVERSE_LSP Objects inserted in the Path message. The other endpoint then creates the corresponding reverse TE tunnel and signals the reverse LSP in response using information from the REVERSE_LSP Object and other objects present in the received Path message. So would it also be correct to say: The forward and reverse tunnels (as defined in [RFC3209]) containing the forward and reverse LSPs of the Single-sided Bidirectional LSP Association on the originating node MUST be the same bi-directional tunnel
(as described in section 3.1.1 of [RFC7551]), albeit both LSPs have reversed endpoint nodes. OR, The Tunnel (as defined in [RFC3209]) containing the forward and reverse LSPs of the Single-sided Bidirectional LSP Association on the originating node MUST be have the same LSP parameters (as described in section
3.1.1 of [RFC7551]), albeit both LSPs have reversed endpoint nodes. ?
<RG> The absence of the previous association in a report. I could not find any relevant text in the RFC 8697. How about following? 5.6. State Synchronization During state synchronization, a PCC MUST report all the existing [acm]
thanks, that helps.
<RG> Ack. Thanks, Rakesh
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call