Re: [mpls-tp] [mpls] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document

[Muralidhar Annabathula <[e-mail]>]

Dear Authors,

1) Referring to sections 1.3, 3.3 and 4.2. LSP-Ping for MPLS-TP LSPs using
non-IP encapsulation. It is mentioned that in certian deployment scenarios
it might be required that LSP Ping (or for that matter any other MPLS-TP
OAM) might be run without IP addressing. In such cases the ingress node MAY
attach a source address TLV.

# My question is that since source address TLV itself is of IPv4 or IPv6
format (as defined in draft-ietf-mpls-tp-ach-tlv-02) how can a sink node
identify the source node in non-ip scenario ? Can we use source address TLV
in non-ip scenario?

2) Referring to scetion 3.3. "If a node receives an MPLS echo request packet
over ACH, without IP/UDP headers and if that node does not have a return
MPLS LSP path to the echo request source, then the node MUST drop the echo
request packet and not attempt to send a response."

# In case there is no LSP based return path and the received MPLS echo
request packet had an IPv4/IPv6 source ACH TLV and the node receiving the
MPLS echo has IP addressing/routing capabilities, in which case shouldn't it
still be able send the response over IPv4 or IPv6?

3) Referring to section 4. "This section specifies how LSP-Ping traceroute
can be used in the context of MPLS-TP LSPs.  The LSP-Ping traceroute
function meets the Adjacency and Route Tracing requirement specified in
[RFC5860].  This function SHOULD be performed on-demand.This function SHOULD
be performed between End Points and Intermediate Points of PWs and LSPs, and
between End Points of PWs, LSPs and Sections."

# For a MPLS section, traceroute may not be applicable as the nodes will
always be adjacent at the corresponding layer.


Regards,
Murali

On Mon, Jun 21, 2010 at 5:07 AM, Loa Andersson <[e-mail]> wrote:

>
> Working Group,
>
> this email is to start poll to adopt
> draft-nitinb-mpls-tp-on-demand-cv-00.txt
> as an MPLS working group draft.
>
> After recent experience, the chairs would like to remind you all
> what it means to conduct a poll to adopt a draft as a working group
> draft.
>
> - Please recall that the IETF does not "vote." Polls of a working
>  group are to gather information to help the chairs make their
>  decisions. Voting is not part of the normal working methods of
>  an IETF working group.
>
> - The "rough consensus" process used in the working group assumes
>  that people expressing opinions are also participating in the
>  development of standards documents.
>
> - Subscription to the list specifically to express an opinion is
>  noticed by the chairs who has access to information on the new list
>  members. Such behavior is not part of the normal working methods.
>
> - The purpose of a poll for adoption is to help the chairs understand
>  the level of support for a document (i.e. who has read it, who
>  believes it is a good starting point for working group work, who
>  will contribute to the work) and whether there are any significant
>  technical issues. Statements of objection must be backed up by
>  proper technical reasons.
>
> So please respond to this poll indicating whether you support the adoption
> of this draft or stating your technical issues.
>
> Please also not that this draft has after a discussion with the
> working group chairs been renamed, it was earlier know as
> draft-nitinb-mpls-tp-lsp-ping-extensions-01.
>
> This poll ends eob July 5.
>
>
> Loa and George
> mpls wg co-chairs
>
> --
>
>
> Loa Andersson                         email: [e-mail]
> Sr Strategy and Standards Manager            [e-mail]
> Ericsson Inc                          phone: [phone]
>                                             [phone]
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>