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

[Matt Hartley <[e-mail]>]

Pavan,

OK. That's reasonable, but it might be worth adding a line to the draft to
say so.

Cheers

Matt

On Thu, Sep 27, 2018 at 4:30 AM Vishnu Pavan Beeram <[e-mail]>
wrote:

> Matt, Hi!
>
>
>
> The purpose of this document is to provide a mechanism to bring up MPLS
> RSVP-TE LSPs on a shared forwarding plane. There is a set of key RSVP-TE
> features/functionalities specified in the Introduction Section that would continue
> to work with this forwarding plane (without needing any special
> extensions). The authors believe that a deployable solution can be
> implemented with this set of features/functionalities.
>
>
>
> If there are any other desirable features/functionalities (that are not
> specified as supported in this document) that can be supported on this
> forwarding plane by introducing a few protocol extensions, then those are
> expected to be discussed separately
> (draft-chandra-mpls-rsvp-shared-labels-np is an example of that).
>
>
>
> Regards,
>
> -Pavan
>
> On Wed, Sep 26, 2018 at 10:56 AM Matt Hartley <[e-mail]>
> wrote:
>
>> Pavan,
>>
>> The problem with lists like this (in general) is that it's not clear what
>> the status is for anything that isn't on the list, and most lists will
>> probably manage to omit *something*. I think there's three reasonable
>> options:
>>
>> 1. State unequivocally that everything works
>> 2. List the functionalities that definitely don't work, and make it clear
>> that everything else does
>> 3. List the functionalities that definitely work, and explicitly make no
>> guarantees about anything that isn't listed.
>>
>> It isn't really clear what you're trying to do here.
>>
>> Note that in this case option 1 isn't on the table because we've already
>> established that nnhop FRR requires further extensions.
>>
>> Cheers
>>
>> Matt
>>
>> On Wed, Sep 26, 2018 at 10:17 AM Vishnu Pavan Beeram <
>> [e-mail]> wrote:
>>
>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>