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

[Vishnu Pavan Beeram <[e-mail]>]

Alex, Hi!

Yes, the bypass tunnel (as indicated by the reference) referred to here is
a regular RFC4090 bypass tunnel.

Regards,
-Pavan

On Tue, Sep 25, 2018 at 11:43 AM Alexander Okonnikov <
[e-mail]> wrote:

> Hi Pavan,
>
> One question regarding ETLD. The draft says (section 5.3.1):
>
>    When an LSP that requests automatic delegation also requests facility
>    backup protection [RFC4090 <https://tools.ietf.org/html/rfc4090>], the ingress or the delegation hop MUST
>    account for the bypass tunnel's label when populating the ETLD.  So,
>    the ETLD that gets populated on these nodes is one less than what
>    gets populated for a corresponding unprotected LSP.
>
>
> I.e. is it assumed that bypass tunnel itself will be regular RSVP-TE LSP?
> Otherwise, if bypass LSP is signalled using shared labels approach, ETLD
> should be decreased for amount of label stack depth, imposed by this PLR
> (ingress or delegation hop) for bypass tunnel.
>
> Thank you.
>
> 16 сент. 2018 г., в 3:03, Vishnu Pavan Beeram <[e-mail]>
> написал(а):
>
> Alexander, Hi!
>
>
> Much Thanks for the review comments. Please keep them coming.
> Please see inline for responses (prefixed VPB).
>
>
> Regards,
> -Pavan
>
>
> On Thu, Sep 13, 2018 at 1:28 PM Alexander Okonnikov <
> [e-mail]> wrote:
>
>> Hi Panav,
>>
>> Questions regarding ETLD:
>>
>> The draft is not clear about signaling of ETLD attribute. It says that
>> ETLD is conveyed as per-hop attribute. Is my understanding correct that it
>> is conveyed as RRO Hop attribute? Probably it could be cleaned to avoid
>> confusion whether ERO or RRO Hop attribute mechanism is used.
>>
>
> [VPB] The ETLD specific protocol extensions are discussed in Section 9.7.
> This section clearly states that the ETLD TLV is carried in the
> HOP_ATTRIBUTES subobject of an RRO object in the Path message. That said,
> the following tweak to the text in Section 5.3.1 should address your
> comment:
>
>
> OLD:
> The ETLD is signaled as a per-hop attribute in the Path message [RFC7570
> <https://tools.ietf.org/html/rfc7570>].
>
>
> NEW:
> The ETLD is signaled as a per-hop recorded attribute in the Path message [
> RFC7570 <https://tools.ietf.org/html/rfc7570>].
>
>
>
>
>>
>> Next, the draft says that:
>>
>> "... If a node is reached where the ETLD set from the previous hop is 1,
>> then that
>> node MUST select itself as the delegation hop.  If a node is reached and
>> it is
>> determined that this hop cannot receive more than one transport label,
>> then that node
>> MUST select itself as the delegation hop. ..."
>>
>> What is purpose of the second sentence/rule?
>>
>
> [VPB] Selecting oneself as a delegation hop ensures that the incoming
> packet will not carry more than one transport label. The second sentence
> above was added to let the transit node have the ability to influence the
> delegation decision if it ran into some local policy/limitation that
> prevented it from receiving more than one transport label. As an
> alternative, the transit node may decide to choose a regular swap label in
> such scenarios and let some downstream node be the delegation hop.
>
>
>>
>> Next:
>>
>> "If there is a node or a sequence of nodes along the path of the LSP that
>> do not
>> support ETLD, then the immediate hop that supports ETLD MUST select
>> itself as the
>> delegation hop."
>>
>> If some node (consecutive nodes) doesn't support ETLD then it doesn't
>> support TE labels. Hence, that node (regular RSVP-TE LSR) will do SWAP and
>> not POP. As a result non-decremented ETLD is OK and immediate hop that
>> supports ETLD not necessary should become delegation hop?
>>
>>
> [VPB] If an intermediate transit node doesn’t support ETLD, it will not
> record ETLD for that hop. The immediate hop that supports ETLD will realize
> that the previous hop doesn’t support ETLD (no recording available for the
> previous hop) and designates itself as a delegation hop.
>
>
>> Also, from Section 9.7:
>>
>> "The ETLD field specifies the maximum number of transport labels that
>> this hop can potentially send to its downstream hop.  It MUST be set to a
>> non-zero value."
>>
>> Strictly speaking it is not correct. ETLD reflects decrementing counter
>> and not capability of some transit node. I.e. if we consider LSP R1-R2-R3,
>> R1 puts value 5 in ETLD,and R2 supports imposing of 2 labels, it doesn't
>> mean that R2 should rewrite ETLD with value 2. It just should decrement
>> value 5. Correct?
>>
>>
> [VPB] I agree that the above sentence can read better. The intent was to
> say – “the maximum number of transport labels that the hop can send in
> relation to its position in the path”. The following tweak to the sentence
> should address your concern:
>
>
> OLD:
> The ETLD field specifies the maximum number of transport labels that this
> hop can potentially send to its downstream hop.
>
>
> NEW:
> The ETLD field specifies the effective number of transport labels that
> this hop (in relation to its position in the path) can potentially send to
> its downstream hop.
>
>
>
>
>> Also, per my understanding it is supposed that in fact ETLD value will
>> not be just decremented, but it will be copied from previous RRO Hop
>> attributes subobject into being inserted RRO Hop attributes subobject with
>> decrementing. May be it would be better to signal ETLD value in LSP
>> Attributes object (and each capable node decrements ETLD value there),
>> while signaling support of ETLD itself in RRO Hop attributes subobject?
>>
>>
> [VPB] The authors did consider the alternative protocol extensions that
> you have specified above. We decided to use the current encoding in the
> draft because there was no good reason to get 2 code-points for ETLD when
> the same objective could be achieved with one code-point.
>
>
>> Thank you.
>>
>> 13 сент. 2018 г., в 20:22, Alexander Okonnikov <
>> [e-mail]> написал(а):
>>
>> Hi Pavan,
>>
>> I'm sorry for delay with answer.
>>
>> If ingress uses regular Path MTU discovery mechanism, it could produce
>> value of MTU lower than actual one. This is because ingress doesn't know
>> MTU per each hop. Let's consider case with four routers: R1 - R2 - R3 - R4.
>> MTU for R1-R2 link is 2000, MTU for R2-R3 is 1600 and MTU for R3-R4 is
>> 2000. By virtue of regular Path MTU discovery mechanism R1 will derive from
>> FLOWSPEC that path MTU is 1600. As soon as R1 doesn't know how many labels
>> in the stack will be on the lowest MTU hop, it can only set LSP MTU to most
>> conservative value (1600 - 4 - 4 = 1592, provided that R4 has advertised
>> implicit null label). In fact actual path MTU is 1596 (1600 - 4 on R2-R3
>> hop). Of course, it could be acceptable, but calculated LSP MTU as more
>> lower than actual as longer LSP path. For correct path MTU discovery
>> ingress needs to know MTU per each hop.
>>
>> Thank you.
>>
>> 6 сент. 2018 г., в 18:27, Vishnu Pavan Beeram <[e-mail]>
>> написал(а):
>>
>> 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 <
>> [e-mail]> 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 [e-mail]://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>>
>>
>