Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt

[Loa Andersson <[e-mail]>]

Nobo,

not that it matters too much but since we done a wg last call and
request for publication what is in the document is the wg consensus.

This wa more than a year ago, it was the LSP Ping TLV and sub-TLV
registry that hanged the draft. It should be OK now and our AD should
be preparing the document for IETF last call and IESG review.

It is of course possible to have comments, but I see it there is nothing
in what you suggest that can't go into a new document.

/Loa

On 2013-08-15 13:00, Nobo Akiya (nobo) wrote:
> Hello Mach,
>
> Many thanks for quick response. Please see further comments inline.
>
>>> Dear Authors, et al,
>>>
>>> Draft adds new reply mode (5 - Reply via Specified Path) which looks
>>> to provide initiator great control on return path. Draft considers
>>> bidirectional LSP, and allows specifying of reverse LSP in a new TLV,
>>> but ... for bidirectional LSP ping, having reply mode to indicate
>>> reverse LSP would appear to take care of large majority of use, and
>>> there'll be no need to encode/decode additional TLV. Is there any reason
>> why reply mode to specify reverse LSP is not added?
>>
>> The draft uses the "reply mode 5 + B bit" to achieve this, using a reply mode
>> to indicate the reverse LSP is an alternate way, we considered this and it
>> also works. The reason not using dedicated reply mode is that we don't
>> want to define too many reply modes, indicating reverse LSP is kind of
>> specifying reply path and using the same reply mode seems reasonable.
>
> We have 8 bits of reply mode, draft is proposing to take value 5/255. I don't think we are crunched to conserve numbers, and reasonable to add another if it make sense. In this case, I think it make sense to add one for "reverse LSP". Regarding "we don't want to define too many reply modes", was that WG rough consensus or was that consensus amongst authors of this draft?
>
>>
>>  From the implementation point of view, IMHO, the two ways have not too
>> much differences, from the operation point of view, there should be no
>> difference.
>
> New value in 8 bit field is certainly much more easier to implement than (new value in 8 bit field + new TLV + logic to handle new TLV).
>
>>
>>>
>>> And reply path TLV allows for initiator to specify a particular return
>>> path, but allows responder to choose different path if initiator
>>> specified one cannot be accommodated. This aspect is very interesting.
>>> Reason being that specifying of the "right" reply mode in echo request
>>> seems to be getting more and more complicated these days.
>>>
>>> For example, bidirectional LSP with some transit nodes non-co-routed:
>>>      - ping:
>>>          * IP reply mode works
>>>          * Reverse LSP reply mode works
>>>      - ping with TTL terminating on mid:
>>>          * IP reply mode works
>>>          * Reverse LSP reply mode may or may not work
>>>      - traceroute:
>>>          * IP reply mode works
>>>          * Reverse LSP reply mode may or may not work
>>>
>>> In above cases, what I would like to specify in most cases is to say
>>> "take reverse LSP as return path if available, otherwise take IP
>>> return path". Yes reply path TLV allows this, but I'm thinking if this can be
>> done in a simpler way.
>>
>> As you said, the reply path TLV allows this. In addition, to localize the failure
>> point, sometime it may need to specify an explicit reply path other than the
>> reverse path and IP return path, that is the main reason why we introduce
>> the reply path TLV.
>
> Yes, for specific use like fault isolation, I think path TLV adds value. It can be another technique in addition to traceroute. For most ping/trace though, path TLV really isn't necessary. I'd like to see things kept simple for most cases, but allow a mechanism for that tricky few percent of cases.
>
>>
>>>
>>> Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4: Reply
>>> via application level control channel Reply mode 6: Reply via reverse
>>> LSP (assume this exists)
>>>
>>> Let's say there existed:
>>>
>>> Reply mode 7: Reply via pre-defined preference
>>>
>>> When responder receives reply mode 7, then return path is chosen from
>>> pre-defined preference list (ex: control-channel > reverse LSP > IP).
>>> Reply mode used can be encoded in the reply mode field of echo rely so
>>> initiator knows which was used.
>>
>> The difficulty is that the responder may not have the ability to judge
>> whether the control-channel, reverse LSP and IP is workable or not. For
>> example, when it thinks that the control-channel is workable, it will always
>> choose it but the control-channel may not workable (e.g., a failure in the
>> middle of the channel) .
>
> Responder does not need to judge whether reverse "path" is workable or not, responder just needs to judge whether reverse "path" is available for use, and that's not difficult.
>
> Reverse LSP reply mode only make sense if something like "pre-defined preference" reply mode also exists ... since transit nodes or FRR path may not have reverse LSP. But "default reply mode" selection by implementations or operators will be simplified if we had something like this.
>
> All this to say, can we discuss a simpler solution via adding couple of new reply modes? :)
>
> I have another question. Draft mentions BFD. I understand the motive behind wanting to control the reverse BFD path on uni-directional LSP. But I don't quite see the entire picture by making use of path TLV. Let's say we bootstrap BFD with LSP ping with path TLV with specific RSVP FEC, so that reverse BFD packets are riding on specified RSVP FEC. That RSVP FEC can become invalid at any time (ex: re-optimization takes place and LSP ID changes). What happens then?
>
> Regards,
> Nobo
>
>>
>> Best regards,
>> Mach
>>
>>>
>>> I see the new TLV useful for specific scenarios, but I've been trying
>>> to see how things (implementations and operations) can be simplified
>>> for those non-specific
>>> (majority) of cases. Was something like above considered as part of this
>> draft?
>>>
>>> Regards,
>>> Nobo
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]