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

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

Alexander Hi!



The intent of the following statement in Section 1 is certainly not to be
evasive (slightly or otherwise).

   Functionalities such as bandwidth admission control, LSP

   priorities, preemption, auto-bandwidth and Fast Reroute

   continue to work with this forwarding plane.



We (the authors) still don’t see any problem with the above statement. But
we’ll go ahead and make a slight adjustment (see below) to address your
concern.

   Key functionalities such as bandwidth admission control, LSP

   priorities, preemption, auto-bandwidth and Fast Reroute via

   facility backup protection continue to work with this

   forwarding plane.



Regards,

-Pavan


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

> Hi Panav,
>
> Ok, 1:1 is not to be supported by this approach. In general, 1:1 has its
> own benefits  - for example, it is more attractive versus N:1 in ring
> topologies. After all, it is FRR too, as N:1 one. My point was that
> description in section 1 is slightly evasive regarding FRR and other
> RSVP-TE properties (PMTUD).
>
> Thank you.
>
>
> 16 сент. 2018 г., в 4:38, Vishnu Pavan Beeram <[e-mail]>
> написал(а):
>
> Alexander, Hi!
>
>
> Please see inline for responses (prefixed VPB).
>
>
> Regards,
> -Pavan
>
> On Thu, Sep 13, 2018 at 1:37 PM Alexander Okonnikov <
> [e-mail]> wrote:
>
>> Hi Panav,
>>
>> From section 7:
>>
>>
>> "If the label type is a delegation label, then the stacking procedure
>> stops at that delegation hop."
>> It is OK for "Stack to Reach Delegation Hop" approach, but it doesn't
>> work for "Stack to Reach Egress", isn't it?
>>
>
> [VPB] The logic specified in Section 7 could be used by any node
> constructing the label stack (this could be the ingress or a delegation
> hop). The sentence immediately following the above quoted sentence in
> Section 7 is important. It currently reads –
> Approaches in Section 5.1
> <https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#section-5.1>
> SHOULD be used to determine how the delegation labels are pushed in the
> label stack.
>
>
> The intent here is to say that if you encounter a delegation label, use
> the procedures outlined in Section 5.1 to determine how the delegation
> labels are pushed in the label stack. The following change to the text
> should address this comment:
>
> OLD:
>
> If the label type is a delegation label, then the stacking procedure stops at that delegation hop.
> Approaches in Section 5.1 <https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#section-5.1> SHOULD be used to determine how the delegation labels are pushed in the label stack.
>
>
> NEW:
> If the label type is a delegation label, then the type of stacking
> approach chosen by the ingress for this LSP (Section 5.1) MUST be used to
> determine how the delegation labels are pushed in the label stack.
>
>
>
>>
>> Also, regarding FRR support. Section 1 says:
>>
>> "Functionalities such as bandwidth admission control, LSP priorities,
>> preemption,
>> auto-bandwidth and Fast Reroute continue to work with this forwarding
>> plane."
>> It seems that shared labels approach supports only facility bypass
>> link-protection. It doesn't support one-to-one link- and node-protection,
>> per my understanding. Facility bypass node-protection is not supported as
>> well (as mentioned in Section 8). Hence, FRR support is very limited, and
>> section 1 needs correction.
>>
>
> [VPB] I don’t see anything wrong with the quoted text. Fast Reroute for
> MPLS-TE LSPs can be realized by either the 1-to-1 protection mechanism
> (detours) or the facility bypass mechanism. The authors don’t intend to add
> procedures for 1-to-1 link/node protection (who needs it?).  The facility
> bypass link-protection procedure is discussed in this draft. The facility
> bypass node-protection procedure is discussed in
> https://tools.ietf.org/html/draft-chandra-mpls-rsvp-shared-labels-np-00
> (this was presented at the last IETF).
>
>
>>
>> Thank you.
>>
>> 13 сент. 2018 г., в 20:28, Alexander Okonnikov <
>> [e-mail]> написал(а):
>>
>> 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.
>>
>> 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?
>>
>> 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?
>>
>> 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?
>>
>> 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?
>>
>> 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
>>>
>>
>>
>>
>>
>