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

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

Alexander, Hi!



As you have observed, the draft doesn’t preclude the use of shared labels
for bypass tunnels (when there is such a desire to do so). The intent of
the text in Section 5.3.1 (that you have highlighted) is to simply say that
the ETLD processing at the ingress/delegation-hop MUST account for the
bypass tunnel’s label(s). The following update to the text should address
your concern:



   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(s) when populating the ETLD.
Hence,

   when a regular bypass tunnel is used to protect the facility, the ETLD

   that gets populated on these nodes is one less than what gets populated

   for a corresponding unprotected LSP.



Regards,

-Pavan

On Wed, Sep 26, 2018 at 10:44 AM Alexander Okonnikov <
[e-mail]> wrote:

> Hi Pavan,
>
> The fact that facility bypass LSP is being established according to RFC
> 4090 doesn't necessary mean that it itself cannot be shared segment RSVP-TE
> LSP. One can assume that the same approach is used for bypass tunnels too
> (to take benefits of shared segment approach). And it could be, unless
> automatic delegation is used for some protected LSP.
>
> Thank you.
>
> 26 сент. 2018 г., в 17:20, 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
>>>>
>>>
>>>
>>>
>>
>