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

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

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
>>
>