Re: [mpls] Clarification reg LSP PING - Draft ver 08- Part 3/3
George Swallow <swallow@cisco.com> Fri, 13 May 2005 20:34 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgrh-0004Ra-RT; Fri, 13 May 2005 16:34:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgre-0004RV-L6 for mpls@megatron.ietf.org; Fri, 13 May 2005 16:34:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06041 for <mpls@ietf.org>; Fri, 13 May 2005 16:34:27 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWh7b-0003Su-Pf for mpls@ietf.org; Fri, 13 May 2005 16:51:02 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 13 May 2005 16:34:19 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4DKYDnK022785; Fri, 13 May 2005 16:34:16 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 16:34:13 -0400
Received: from swallow-mac.cisco.com ([10.86.241.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 16:34:13 -0400
Received: by swallow-mac.cisco.com (Postfix, from userid 501) id CC3B82F61EA; Fri, 13 May 2005 16:34:10 -0400 (EDT)
Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id 15F222F61DE; Fri, 13 May 2005 16:34:10 -0400 (EDT)
To: "M. elk" <elkou141061@hotmail.com>
Subject: Re: [mpls] Clarification reg LSP PING - Draft ver 08- Part 3/3
In-reply-to: Your message of "Mon, 02 May 2005 14:27:24 +0300." <BAY21-DAV18343A6833030F874DF4E0B4270@phx.gbl>
From: George Swallow <swallow@cisco.com>
X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1
Date: Fri, 13 May 2005 16:34:08 -0400
Message-Id: <20050513203410.CC3B82F61EA@swallow-mac.cisco.com>
X-OriginalArrivalTime: 13 May 2005 20:34:14.0040 (UTC) FILETIME=[204F4180:01C557FB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c2c13da073bbdd073b64ce7ea2347217
Cc: mpls@ietf.org
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Sender: mpls-bounces@lists.ietf.org
Errors-To: mpls-bounces@lists.ietf.org
Although the last call closed a month prior to your messages, I felt
your comments were serious enough to give them full consideration.
Thanks for the close read. Attached are my responses.
...George
========================================================================
> A- Section 3 , Packet Format A1. For "If the normal IP return path is
> deemed unreliable ,one may use "Reply via an IPV4/IPV6 UDP Packet with
> Router Alert " .
>
> Actually it was not clear how using such mode of reply will
> increase the chance to receive the reply packet . In some
> external presentation , it is explained as the reply will be
> routed in a transient LSR by the RP(instead of the LC ) and as
> such the reply packet will be correctly routed in the case where
> the FIB of the LC is corrupted . May be it worth to document this
> explanation into the draft .
I don't believe this draft is the proper place for this kind of
tutorial information.
> What about "Reply and log " , in this case the operator could
> check the remote end to see if any log in case of no reply
> received . For sacalability , The receiving station count the nbr
> of echo request for each (Source IP Address,Source UDP port ,
> Sender Handle). and/or "Reply Via NMS" ,path from any node to NMS
> is the most watched path (from OPS perspective) and we could
> assume it is up (otherwise it is currently under attention of the
> operator ) . In this mode the node encapsulate the reply in
> IP-in-IP through the NMS .
The entire philosophy of ping is based on most of the work being done
at the point where the ping is initiated. If an implementation wants
to provide logging they can. If they want to allow it to be turned on
and off they can. They just have to tell the tail end prior to
sending the pings.
> A2.For "TLVs may be nested within other TLV ......"
> The above indicate that we could liberally nest TLV within TLV ,
> but actually it is not the case . We do have strict TLV and
> SUB-TLV as the "Type" field of the TLV and SUB-TLV do Overlap .
> In other word : TLV could not appear inside another TLV . SUB-TLV
> could not appear unless inside TLV .
Updated text to:
Types are defined below; Length is the length of the Value field in
octets. The Value field depends on the Type; it is zero padded to
align to a four-octet boundary. TLVs may be nested within other
TLVs, in which case the nested TLVs are called sub-TLVs. Sub-TLVs
have independent types and must also be four-octet aligned.
> A3. For Target-FEC-Stack TLV contain 1) Sub-TLV LDP IPv4 and 2)Sub-TLV VPN IPV4 Prefix
> the length could be : i) 24 or j) 20 ?
> For 24 , each SUB-TLV is aligned to four-octet-boundary .
> For 20 , the TLV ( as a whole) is aligned to four-octet-boundary
>
> If the draft recommend the way to align each sub-TLV to
> four-octet-boundary(length = 24) ,but in such case why the length
> value of the SUB-TLV was chosen not to include the padding byte
> ?? ex: For LDP IPv4 the length is 5 instead of 8 . The "length"
> field should specify the actual size (in this case 8) used on the
> wire , the receiving node from the "Type" field could determine
> that the used part is just 5 . Else (length = 20) , could we
> modify the example to include more than one Sub-TLV to make the
> case clearer .
Actually the answer is 32. Updated the example as follows:
The Length for this TLV is 5. A Target FEC Stack TLV which contains
an LDP IPv4 FEC sub-TLV and a VPN IPv4 FEC sub-TLV has the format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 FEC) | Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> A4. For the Para (page 10) "Types less than 32768 ....etc " .
> may be changing the word "mandatory" to "mandatory supported " .
>
> For the Para (page 10) "Types greater than .....etc " .
> may be changing the word "optional " to "optionally supported"
>
> This will make it more clear that "mandatory" and "optional"
> refer to the support of the node for such TLV's and not the
> existence of such TLV in the packet .
Fixed.
> A5. Section 3.2 page 12 .
>
> for the Sub-TLV "RSVP IPv4 Session Query" , better to be named
> as just "RSVP IPv4 Session" . same for IPv6 .
Changed to RSVP IPv4 LSP
> A6. Page 12 , the Para "say LSR X wanted ...etc ".
> is this applicable to "LSP Trace" also ???
>
> For the case where RSVP Tunnel end at the destination PE (Target
> FEC TLV could contain RSVP IPV4 session Sub-TLVand IP VPN Prefix
> Sub-TLV. or Target FEC could contain just the IP VPN Prefix
> Sub-TLV ) , is it workable for "LSP Trace".
>
> (The point that in case the target FEC contain just the IP VPN
> Sub-TLV , the transient LSR will find no Sub-TLV FEC which
> correspond to the RSVP LSP or the LDP LSP so how this LSR could
> check ) .
Only checks if there's a valid DS map (section 4.4)
> The confusing point that a transient LSR in some cases is able
> to check the received label against the target FEC ,and in other
> cases it is not possible . Is it correct ?? If yes : How the
> transient LSR could differentiate .
>
> N.B: may be the answer to above is within section 4.4 (Receiving
> an MPLS echo request) ,but i am having difficulty to understand
> section 4.4 .
>
> A7. NIL FEC
> One usage for "NIL FEC" is documented in section 4.2 . Any other
> usage not documented in the draft ???
Not at this time.
> B. Downstream Mapping TLV , Page 20
>
> B1 . For "Only one downstream mapping request may appear in am echo
> request "
> change "downstream mapping request" to "downstream mapping
> object" .
done.
> B2. For "Otherwise Downstream mapping objects should include a
> downstream mapping object
> ............could be forwarded" .
> The DS TLV do not include DS TLV . May be rewriting the
> above as
> "Otherwise ,the echo reply should include a downstream
> mapping object .......could be forwarded".
fixed.
> B3. Moving the "I" Flag to be global flag .
> why : The Requirement is to know the Destination "
> interface and label stack" object .
> Currently: U have to Trace the full path to get those info
> .
> what is needed : Just using PING and requesting the
> "Interface and label Stack" object to be
> included in the echo reply .
You can send a DS without setting the TTL low. Use a neighbor address
of 127.0.0.1 (unknown).
> B4. Multipath Type , Page 22
>
> The Sending LSR have the following to influence the multipath
> :
> i) The destination IP , which need to be chosen from the 127/8
> range .
> and/or
> ii) The Source UDP Port .
>
> The Transient LSR (where the TTL expire) have the following info
> :
> i) the source IP ,Destination IP and the source UDP Port .
> ii) The received label Stack , say {Ln,Ln-1,....L1}
> iii) The Received DS Mapping TLV
>
> Case 1- The "N" Flag set to indicate non-IP Packet
>
> Sub-case 1a- The LSR consider only the Received Label stack . Run
> is Hash function (assuming avail of
> more than one interface , say intfa and
> intfb ) on the received label stack to find out on which
> interface it will be forwarded , say
> Intf_a
> The LSR reply with DS mapping TLV with
> intfa details and with "Multipath type" = zero .
>
> Sub-Case 1b- The LSR consider the Received label Stack and the
> info of the multipath type
> (Multipath Type = 9 or Zero ) received
> . For simplicity assume no info for the "Multipath Type"
> i.e.: "Multipath Type" = Zero .
1a is correct. If there's no multipath info then you don't reply with
multipath info (send back type 0). You just show what interface you
would have forwarded this packet on.
> The LSR run his Hash and find 2 bit-masked
> label set (say bit_masked_set_1 and bit_masked_set_2).
> one which will forward the packet to intfa
> and the other to intfb . The LSR reply by 2 DS mapping
> TLV both with "MultiPath type" = 9 . But :
> the only possible values for both set (Bit_masked_set_1 ,
> Bit_masked_set_3) are the Explicit null
> label or Router Alert label. is it correct ???
> Say Bit_masked_set_1 resolve to Explicit
> null , could it be used by the sending LSR more than once .
> ex:
> {Ln,Ln-1,Ln-2,......,Explicit_null,Explicit_null,L1} and still get
> forwarded to intfa ???.
> is it location independent ,ex:
> {Ln,Explicit_Null,Ln-1,.......L1} same as
> {Ln,Ln-1,Explicit_null,Ln-2,.....L1} ,
> both will be forwarded to intfa ???.
I don't get the meaning of the list in parens. If it's a label stack
the answer is no.
> For Case 1 , Is it sub-case 1a or Sub-case 1b ??? .
>
> Case 2 - The "N" Flag cleared to indicate IP Packet .
>
> Sub-Case 2a- The Transient LSR consider the following when
> calculating the hash :
> i) The Source IP Address .
> ii) The Source UDP port .
> iii) The multipath info received ( Multipath
> Type = Zero,or 2 or 4 or 8 )
>
> Sub-case 2b- The Transient LSR consider the following when
> calculating the hash :
> i) The Source IP Address .
> ii) The Source UDP port .
> iii) The multipath info received ( Multipath
> Type = zero, or 2 or 4 or 8 )
> iv) the received label stack .
>
> Sub-Case 2c- The Transient LSR consider the following when
> calculating the hash :
> i) The Source IP Address .
> ii) The Source UDP port .
> iii) The multipath info received ( Multipath
> Type = zero, or 2 or 4 or 8 or 9 )
> iv) the received label stack .
>
> which sub-case is valid ??? .
Depends on how the implementation does it's hashing. So 2b, and 2c
(they seem to be the same) is correct. But if the implementation
doesn't include the label stack when forwarding then it doesn't use it
here either.
> B5. The Filed "Depth Limit" ,page 22
> Guess this filed should be ignored (or set to zero) when the
> DS mapping TLV is part of Echo request .
> This field is populated by the LSR sending the echo reply to
> indicate the number of labels out from
> the received label stack considered in the hash . is it
> correct ?.
Not quite. Some hardware has limitations on how deeply it can inspect
a packet in the fast path. If at a certain label stack depth it has
to alter it's behavior (such as I hash only on the bottom label as
long as there are 4 or fewer labels, but I hash on the 4th label if
there are more) then the Depth Limit is there to let you know to
whatch out for alternate behavior with deep label stacks.
> if yes : consider
> the Transient LSR received label stack {L3,L2,L1} and DS
> Mapping TLV
> The transient LSR reply with DS mapping TLV with label field
> {L4,L2,L1} and Depth-limit=2
> is it mean that LSR will do the hah over {L3,L2} or {L2,L1}
> or even {L3,L1} ???
>
> B6. Protocol , page 23
> Consider PE1----P1----P2----PE2 .
> The PE1 send echo request with TTL=1 and DS mapping TLV.
> The DS mapping TLV contain the 2 label , {(L1,LDP),(L2,IP
> VPN)}
> P1 send echo reply with DS mapping TLV .
> The DS mapping TLV contain the 2 label as :
> i) {(L3,LDP),(L2,IP VPN)}
> or
> ii) {(L3,LDP),(L2,Unknown)}
Any label that you haven't processed you leave as is.
> In the first case , P1 copy the protocol of L2 from the DS
> mapping TLV received .
> In the 2nd case ,P1 have no self info which protocol issued L2
> so it mark L2 with Unknown protocol
> irrespective of what protocol was associated with L2 in the
> received DS mapping TLV .
>
> so which case the draft is calling for ?? .
>
> B7. Multipath info encoding , page 23
>
> B7.1 For the first Para "The multipath info encodes labels
> ..........".
> The sentence "The contents of the fields are shown in the
> table above",
Added pointer back to section.
> It seems the table is missing .
> The sentence "Label and Address pairs .....", in this ver
> of the draft the "multipath type" = 1 = label
> is deprecated . Also , what it meant by "pairs" ??? .
added some clarifying text
> B7.2 For "multipath type" = 8 or 9 encoding . could we have an
> example to make it clear .
Added examples.
> B7.3 For the Para " if the received multipath information is
> ........".
> For the sentence " if the received multipath information
> is non-null," , is it mean
> "If their is DS mapping TLV received " ???.
>
> For " if the received multipath information is null" , is
> it mean
> " If their is no DS mapping TLV received " .
>
> For "The type must be set to 0" , is it Zero or 7
> (no-match) ??
0 - we dropped 7.
> Re-writing the Para as :
>
> "If their is Downstream Mapping TLV received ,the labels
> and IP address MUST be picked from
> the set provided . if none of these labels or addresses
> map to a particular downstream interface ,
> then in the downstream mapping TLV for that interface in
> the echo reply ,the multipath type must
> be set to 7 (no match) . If their is no DS mapping TLV
> received ,the receiver LSR simply return no
> Downstream mapping TLV in the echo reply ".
rewrote as:
labels or addresses map to a particular downstream interface, then for
that interface, the type MUST be set to 0. If the received multipath
information is null, (i.e. Multipath Length = 0, or for Types 8 and 9
a mask of all zeroes) the receiver the type MUST be set to 0.
>
> B7.4 for the Para "For Example ,suppose ..........." .
> my understanding that the address should be in the 127/8
> range ???.
Changed ranges.
> For " with Hash key Type 7 " , in this ver of the draft the
> Hash key is renamed multipath Type .
> Also , in this ver multipath-Type = 7 is not defined (only 0
> ,2,4,8 and 9 ).
Fixed, now 0.
> For " The Head end reflects ...." , could we elaborate in
> the draft how this is done .guess this
> will make it clearer for the reader .
>
> An example of using label to exercise path ,will be very
> useful .
>
> B7.5 For the Para "Note that computing .....".
> Could we have it as explicit notification(instead of
> implicit) ,say by setting certain global flag in the
> echo reply .
I think it's clear enough. The info is there.
> B7.6 For " If a packet was originated with TTL n>1 arrived with
> outermost label L at LSR X ....".
> Guess it could be more clear as :
> " If a packet was originated with TTL n>1 arrived with
> outermost label L with TTL=1 at LSR X ..."
OK.
> B7.7 For "Note that there are multiple downstream label fields in
> each TLV as the incoming label L may be
> swapped with a label stack ".
>
> Consider PE1----P1---Tunnel1--P2---PE2
> testing for IP VPN LSP using trace .
> Case 1 :
> PE1 send echo request with DS mapping TLV with label fields
> : {(L1,LDP),(L2,IP VPN)}
> P1 reply include DS mapping TLV with label fields
> {(L3,RSVP-TE),(L4,LDP),(L2,IP VPN)}.
>
> OR
> Case 2 :
> PE1 send echo request with DS mapping TLV with label fields :
> {(L1,LDP)}
> P1 reply include DS mapping TLV with label fields
> {(L3,RSVP-TE),(L4,LDP)}.
>
> is it case 1 or 2 ??
> The above note in the draft could be understood that it is
> case 2 ??.
> while the definition of "downstream label " in page 23
> ,indicate it is case 1 .
Deleted the note as it is misleading.
> B7.8 Page 25 . For the Para "The case where X is the ......." , and
> the Para "the set of downstream router " . Guess by swapping the
> position of the 2 Para the sequence of info will be more clearer .
I don't think that change would be helpful.
> B7.9 Page 25 . In the Para " The set of downstream routers ....." .
> for " The "No of multipaths" is the number of IP
> address/Next label fields". could U pls explain ???.
Old text. Deleted.
> B7.10 . The case of RSVP-TE Tunnel
> consider :
>
> PE1--P1--P2--P3---P4--P5--PE2
> we do have RSVP-TE tunnel from P1 to P4 .
> testing for IPv4 VPN
>
> PE1 will send Echo Request with DS mapping TLV contain the label field
> {(L1,LDP),(L2,IP VPN)}
>
> case 1 : The RSV-TE Tunnel is Pipe or Short-Pipe
> P1 will reply with echo reply with DS
> mapping TLV contain the label field
> {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS
> IP address is P4 router_id , the DS
> interface is the Tunnel tail-end which is
> normally P4 router_ID. From this info PE1
> will know that his traffic will be
> encapsulated into a Tunnel which start
> from P1 .
>
> believe is beneficiary if the reply from
> P1 could also include the following info :
> i) That the Tunnel is Pipe or Short-Pipe
> mode > ii) The Tunnel ID . > > For both ,
> it is satisfied by a Tunnel object (same
> as specified in
> draft-ietf-ccamp-tunproto-01).
The intention was all along to have this kind of functionality be part
of that draft. (Not planning to add it to this one.)
> PE1 now have full info , it is known that traffic will be encapsulated in an RSVP tunnel which
> start at P1 and end at P4 .also the Tunnel ID is known .
>
> Case2 : The RSVP-TE Tunnel is Uniform mode .
>
> P1 will reply with echo reply with DS mapping TLV contain the label field
> {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS IP address is P2 router_id , the DS interface
> is P2 interface connecting to P1 .
> From this info PE1 will know that his traffic will be encapsulated into a Tunnel which start from
> P1 .
>
> believe is beneficiary if the reply from P1 could also include the following info :
>
> i) That the Tunnel is Uniform mode .
> ii) The Tunnel ID .
> iii) the incremental step in TTL if chosen to skip the
> tunnel transient node
>
> "i" and "ii" same as case 1 . for "iii" ,P1 will reply with "3".
> In other word ,if PE1 need to skip the tunnel just add 3 to the
> TTL used to reach P1 . Any "Unused" bit's in the Tunnel object could
> satisfy this requirement. PE1 now have full info , it is known that
> traffic will be encapsulated in an RSVP tunnel which start at P1 and
> end at P4 .also the Tunnel ID is known . PE1 could decide to include
> the tunnel in the trace (continue to increment the TTL by 1 ) or to
> skip it (add 3 to the TTL used to reach P1).
Same as above.
>
> B8. Page 26 , "Interface and Label Stack" object
>
> B8.1 This TLV considered to be optional TLV . could we state
> that if the "Return code" field is non-zero, this TLV should be
> included mandatory in the echo reply or at least , for all error
> code where the <RSC> is included/populated it is mandatory to
> include this TLV in the echo reply.
My intention is that one SHOULD do this. However in certain
circumstance an operator may choose for security reasons not to send
such information. So I don't see how it can be Mandatory.
> B8.2 In "IPv4 Interface and label Stack" Object For " If the
> Address type is "No Address", ..." . the format of this TLV do
> not contain any field as "Address type" ?? or this ref to the
> field of "Address Type" in the received Downstream mapping TLV ??
> If yes : The "Address Type" field in the received DS TLV can not
> have the value "NO Address" , i.e.: "No-Address" is not a defined
> value . ???.
The "No address" should have been dropped. It's hanging around from a
previous version of the DS map. Added an Address Type field to the
this object to be consistent with the DS mapping.
> B7.11 Consider the following :
>
> PE1--------P2
> PE1 is trace testing for LDP IPv4 . Out from P2 , it do
> exist qty 2 ECMP , one of those path the mpls forwarding is
> disabled . PE1 send Echo request with DS Mapping contain
> label field {(L1,LDP)}. P1 will send Echo rely with
> "Return code"= 9 and <RSC>=1 , in addition : P1 will
> include (as normal) 2 DS mapping TLV . The first one
> (where Mpls is enabled ) contain label field ((L2,LDP).
> The 2nd one (where Mpls is disabled) contain no label field
> .
>
> PE1 , will be able to conclude that the "return code" is
> applicable to the 2nd interface .
>
> Is the above is correct implementation .
The return code applies only to the label stack of the received
packet. We'll say IF1 is the first interface and IF2 is the second
interface. So if that packet is going out IF1, then it would send a
return code of 8, and if it went out IF2 the return code would be 9.
Unfortunately the DS map depends on the incoming label, not the out
going label. So there are a number of possibilities. If the label
operation for interface 2 is POP and there is only one label in the
label stack (as in your example) then you would show the labels that
would be mapped to IF2, and you would return a null label stack. If
there was a label stack on the packet, then you would do as you say
above.
> C. Page 29 , Theory of Operation
>
> C1. Page 29 , In the Para "FEC stack can be more complex .........".
>
> For " The FEC stack would contain two sub-tlv's ,the first
> being a VPN IPv4 prefix,and the second being an LDP IPv4
> prefix".
>
> To follow the way the target FEC TLV is built also the
> convention used in page 12 Para " say LSR X Wanted ....", the
> above sentence to be re-written as : "The FEC stack would
> contain two sub-TLV's,the first being an LDP IPv4 prefix,and
> the second being a VPN IPv4 prefix." >
Changed to bottom / top
> C2. Page 29 , in the Para "When an MPLS echo .....".
>
> For " the receiver is expected to do a number of tests that
> verify ...". could the draft elaborate on what are those
> tests . which are applicable to the egress node and which are
> applicable to a transient node . This will help to
> understand/clarify the procedure in section 4.4 "Receiving an
> MPLS Echo Request".
The text now points to section 4.4.
> C3. Page 30 , in Para "to achieve some degree ..............".
> For " "Multipath Exercise" sub-TLV ".
> no such sub-TLV in this ver of the draft , may be to replace with :
> " Multipath field ,part of the downstream mapping TLV ".
Changed to "Multipath Information"
> For "The Ingress can then send MPLS echo request that exercise
> these paths". Could the draft elaborate how this is done .
I don't believe this draft is the proper place for this kind of
tutorial information.
> C4. Page 30, in Para "To detect certain ......."
> For "will prevent a router from forwarding such packet out
> unlabeled interfaces". guess the router here is the PHP
> router and above could be re-written as : " will prevent the
> PHP router from forwarding such packet out unlabeled
> interface."
#I don't think the proposed wording is an improvement.
> C5. Page 31 , Para "The sender chooses .....".
> For "However, a sender MAY choose to send a group of echo
> requests with the same sequence number to improve
> .............". Guess this is more relevant/practical in
> trace mode . and it could be re-written as : "However , in
> trace mode a sender MAY choose to send a group of echo
> requests ,having the same TTL value, with the same sequence
> number to improve ..............."
I don't think we should make a change here. One might also do this
with just a ping in a high error environment.
> C6.Page 31 .Section 4.4 "Receiving an MPLS Echo Request".
>
> Beleieve despite almost 3.5 page ,this section is squeezed .
> The Section list/state procedure/algorithm but not muh reg the
> logic itself behind this procedure/algorithm. As too many
> clarification requested in this section , they will be sent in
> seperate msg .
>
> C7. Page 36 , section 4.6 "Receiving an MPLS Echo Reply".
>
> Para " if the echo reply contains downstream mappings , and X
> wishes to traceroute further ,...." for " it should copy the
> downstream Mappings into its next Echo Request (with TTL
> incremented by one)."
>
> Why "Downstream Mappings" have an "s" . node X should copy a
> single DS mapping object in the Echo Request - the DS mapping
> object which correspond to the path which X need to follow- .
Changed to "it SHOULD copy the Downstream Mapping(s) into its next echo request(s)
>
> D. Typing Error
>
> D1. Page 31 , Para "An MPLS echo Request Must have .........".
> for " the echo request SHOULD a downstream mapping TLV".
> "Have " is missing .
Done.
> D2. Page 9 , "The LDP IPv4 TLV has the following format : "
> Replace "TLV" with "Sub-TLV".
Done.
> D3. Page 9 , " A FEC TLV which contain just ......."
> Replace "FEC" with "Target FEC Stack "
Done.
> D4. Page 22 , "will serve to execise this path" .
> missing "c".
Done.
> D5. Page 23 , "Null labels are explicitly inluded ..."
> missing "c".
Done.
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls