Re: [mpls] Requesting WG LC for draft-ietf-mpls-rsvp-shared-labels

Alexander, Hi!

I apologize for the delayed response.

This draft does not propose any changes to the standard RSVP MTU signaling
procedures (Int Serv object specific signaling procedures). After the
initial signaling sequence is complete, an ingress implementation (RFC3209)
would typically take the path MTU learnt via signaling, run it through some
local logic and then arrive at an MTU value that can be assigned to the
LSP. This local logic typically involves deducting the number of bytes in
the label stack used for the LSP from the path MTU learnt via signaling.
The ingress implementation supporting this draft will rely on the Resv RRO
to accurately determine the max-number of labels pushed along the path of
the LSP (note that with delegation, downstream hops can impose label
stacks) and account for it in the local logic used to arrive at the MTU
value assigned to the LSP.

I hope this addresses your question.

Regards,
-Pavan

On Tue, Aug 7, 2018 at 12:22 PM Alexander Okonnikov <
alexander.okonnikov@gmail.com> wrote:

> Hi Pavan,
>
>
> Regular RSVP-TE LSPs use standard RSVP path MTU discovery mechanism. That
> one cannot be used "as is" for approach described in the draft, and the
> draft doesn't address path MTU identification. Is it to be considered?
>
>
> Thank you.
>
> 26.07.2018 06:07, Vishnu Pavan Beeram пишет:
>
> Chairs, Hi!
>
> As mentioned (in our presentation) in last week's WG session, we believe
> that the draft is sufficiently baked and ready to progress to the next
> stage. We would like to formally request this draft to be considered for WG
> LC.
>
> Regards,
> - Pavan (on behalf of the authors)
>
>
> _______________________________________________
> mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>