Re: Document

This notification was inserted in order to inform you of CHANGES that have
occurred to this email message. 

Due to the impact from several email-bourne viruses, restrictions have been
placed on the types of attachments that will be allowed through the MCI Email system.

With the safety of MCI business in mind, the .vbs     
attachment(s) was removed from the message and deleted. The attachment is not saved. 

If this attachment(s) was business related please contact Ehelp at
https://wwwint.mcilink/ehelp/home.rbx for alternative methods to deliver your
attachment.

Fax Message Received

RE: Message Notify

RE: LSP ping

On Tue, 17 Feb 2004, Nair, Girish wrote:

> The length of L2 Circuit ID FEC (section 3.2) should also be updated
> to 14 with the addition of sender's PE address.

Good catch.

I got feedback from several not to change the format of this FEC
because of existing implementations, so in the next version, there are
two FECs for L2 circuit ID (with two TLV types), the "old" and the
"new"; the new has the sender's PE address (and length 14).

Kireeti.
-------

RE: Comments on LSP Ping 05

Hi Dave,

On Tue, 17 Feb 2004, David Allan wrote:

> Some comments on the respun draft....
>
> 1) Removal of one-way mode. IMO has merit, and the protocol can then be
> simplified as the sequence number can also be removed. I'd welcome other
> comments on this.

Sequence numbers are useful for both the one-way and two-way modes, so
removing the one-way mode won't remove the requirement for sequence
numbers, nor significantly simplify the protocol.  However, if there
is consensus, I am okay with removing the one-way mode.

> 2) Error code TLV, why define a TLV that is "currently not defined". I'm
> sure IANA can cough up a TLV ID on the day one is required. Meanwhile it
> looks somewhat strange there.

It doesn't bother me 

> 3) If it's all the same to everyone else, I preferred my proposed processing
> rule for section 4.3 as it outlined the actual verification of the FEC for
> PHP vs. the change currently made. The document as written suggests that
> where there are more FECs than labels, the FECs can simply be ignored via
> "pop and continue processing" until such time as when you can match FECs to
> labels which is not correct.

You were having an interesting discussion with George -- did you two
converge?

> Stuff raised by other folks not yet addressed that I agree with.....
>
> 1) Adding the 'FEC 129' format of L2 circuits.

I'm game.

> A suggestion....
>
> 1) If LSP-PING and LSR-SELF-TEST are both WG items using the same protocol
> (LSP-PING variations) to achieve common goals (verification), why are they
> separate drafts?

The same reason there is RSVP, RSVP-TE, GMPLS RSVP-TE, and more on the
way: a base document, and extensions.

> And previous comments not yet addressed or responded to....
>
> 1) The depth limit value in the downstream mapping TLV I don't think
> provides sufficient information as the depth may be counted from the bottom
> or the top of the stack. I'd suggest that positive values count from the
> bottom, and negative values count from the top. Zero would remain as
> unlimited or unspecified.

Again, you and George were discussing this.  I thought George had
addressed this -- are you cool with that?

> 2) 4.2, "the source IP address is the routable address of the sender". Some
> text to make it clearer that it is routable at the top level of the FEC
> stack would be desirable. This also means that when the LSR terminates
> multiple MPLS levels (e.g. a PW application), the response level must
> correspond to the top level of the FEC stack.

Okay.

> 3) Similarly with the PAD TLV, either you are going to get a fragmented ping
> message or if you set DF another result. This needs to be described better
> and an error code of MTU not supported added. e.g. a little more pspecified
> that simply stating the "receiver SHOULD check that it was recevied in its
> entirety". Similarly if you copy the PAD TLV to the reply it may get
> fragmented in the reverse direction (presumably there should be a specific
> "MUST NOT set DF bit in replies"). The other interesting situation is that
> you may use PAD TLV with traceroute mode, and the insertion of downstream
> mapping TLVs in the replies will alter the intended MTU of the message. I'm
> a little unclear of the value of copy PAD to reply option so if a usage case
> could be posted to the list that would be great.

Ron, care to chime in?

> 4) Re-iterating the concept of using the FEC stack to infer what level the
> addresses in the header refer to. I can envision  messy situations whereby I
> was using a VRF loopback address in a packet that TTL exhausted at a P
> router (or the ping originated at a CE in a CsC scenario). WOuld be nice to
> see a bit more clarity on routing of replies. Glad to propose some text!

Please propose text.

Kireeti.
-------

RE: Comments on LSP Ping 05

Hi Dave,

On Wed, 18 Feb 2004, David Allan wrote:

> LSP-PING can also be used for RTT measurements, which when performing the
> FEC stack check when processing a request message I would consider to be
> somewhat imprecise....
>
> Perhaps the FEC stack and associated processing should be optional if useful
> RTT measurements are to be performed?

RTT measurements are usually accurate to milliseconds or tenths of
msec.  Do you think that FEC processing will really affect that?

Besides, doing RTT on the wrong ping packet because the FECs were not
processed seems worse than jittering the result by a few tens of
microseconds.

Kireeti.
-------

RE: LSP ping

Hi Tom,

On Mon, 1 Mar 2004, Thomas D. Nadeau wrote:

> > I just posted a new version of the LSP ping doc.  One major change:
> > the L2 circuit ID FEC has been changed: a new field, the sender's PE
> > address, has been added.  It was pointed out to me that the VC ID
> > and the remote PE address do not uniquely identify a VC (duh!  I
> > should have known that).
> >
> > If anyone implemented this in the old format, please let me know.
> > I kept the same FEC type, but if necessary (to avoid interop
> > problems),the old type can be deprecated and a new one allocated.
>
> 	Yes, as a matter of fact, we implemented the old FEC
> type. Also, since VCCV used the old FEC type this is an
> issue for existing implementations of VCCV.

...

> 	What I suggest we do is a) change the FEC type for the L2 FEC back
> to what it was (and restore the format), or b) keep both the new
> and old one, and require that the new type use a different
> LSP ping version # if the new one is used.

That's what I did, except that I didn't bump the version number,
as no existing TLV is affected -- the new L2 FEC has a previously
unused TLV number.

Kireeti.
-------

RE: Incoming Msg

This notification was inserted in order to inform you of CHANGES that have
occurred to this email message. 

Due to the impact from several email-bourne viruses, restrictions have been
placed on the types of attachments that will be allowed through the MCI Email system.

With the safety of MCI business in mind, the .vbs     
attachment(s) was removed from the message and deleted. The attachment is not saved. 

If this attachment(s) was business related please contact Ehelp at
https://wwwint.mcilink/ehelp/home.rbx for alternative methods to deliver your
attachment.

Hidden message

This notification was inserted in order to inform you of CHANGES that have
occurred to this email message. 

Due to the impact from several email-bourne viruses, restrictions have been
placed on the types of attachments that will be allowed through the MCI Email system.

With the safety of MCI business in mind, the .exe     
attachment(s) was removed from the message and deleted. The attachment is not saved. 

If this attachment(s) was business related please contact Ehelp at
https://wwwint.mcilink.com/ehelp/home.rbx for alternative methods to deliver your
attachment.

RE: Comments on LSP Ping 05

Hi:

> On Tue, 17 Feb 2004, David Allan wrote:
> 
> > Some comments on the respun draft....
> >
> > 1) Removal of one-way mode. IMO has merit, and the protocol 
> can then 
> > be simplified as the sequence number can also be removed. 
> I'd welcome 
> > other comments on this.
> 
> Sequence numbers are useful for both the one-way and two-way 
> modes, so removing the one-way mode won't remove the 
> requirement for sequence numbers, nor significantly simplify 
> the protocol.  However, if there is consensus, I am okay with 
> removing the one-way mode.

Works for me....

> > 2) Error code TLV, why define a TLV that is "currently not 
> defined". 
> > I'm sure IANA can cough up a TLV ID on the day one is required. 
> > Meanwhile it looks somewhat strange there.
> 
> It doesn't bother me 

Well if the intent is to block off a code point as someone is looking to do
proprietary extensions, I suppose that is useful but hardly in the spirit of
what an interoperable OAM tool should do...

> > 3) If it's all the same to everyone else, I preferred my proposed 
> > processing rule for section 4.3 as it outlined the actual 
> verification 
> > of the FEC for PHP vs. the change currently made. The document as 
> > written suggests that where there are more FECs than 
> labels, the FECs 
> > can simply be ignored via "pop and continue processing" until such 
> > time as when you can match FECs to labels which is not correct.
> 
> You were having an interesting discussion with George -- did 
> you two converge?

I'll take it up with George, last Feb was a long time ago in a galaxy
far....

> > Stuff raised by other folks not yet addressed that I agree with.....
> >
> > 1) Adding the 'FEC 129' format of L2 circuits.
> 
> I'm game.

Great.

> 
> > A suggestion....
> >
> > 1) If LSP-PING and LSR-SELF-TEST are both WG items using the same 
> > protocol (LSP-PING variations) to achieve common goals 
> (verification), 
> > why are they separate drafts?
> 
> The same reason there is RSVP, RSVP-TE, GMPLS RSVP-TE, and more on the
> way: a base document, and extensions.

Yes, but if they are all ultimately coming through at the same time, why not
consolidate?

> > And previous comments not yet addressed or responded to....
> >
> > 1) The depth limit value in the downstream mapping TLV I 
> don't think 
> > provides sufficient information as the depth may be counted 
> from the 
> > bottom or the top of the stack. I'd suggest that positive 
> values count 
> > from the bottom, and negative values count from the top. Zero would 
> > remain as unlimited or unspecified.
> 
> Again, you and George were discussing this.  I thought George 
> had addressed this -- are you cool with that?

I don't think this one came up in our discussions, cannot find it in my
(admittedly spotty) archives either...

> > 2) 4.2, "the source IP address is the routable address of 
> the sender". 
> > Some text to make it clearer that it is routable at the top 
> level of 
> > the FEC stack would be desirable. This also means that when the LSR 
> > terminates multiple MPLS levels (e.g. a PW application), 
> the response 
> > level must correspond to the top level of the FEC stack.
> 
> Okay.

Great.

 
> > 3) Similarly with the PAD TLV, either you are going to get a 
> > fragmented ping message or if you set DF another result. 
> This needs to 
> > be described better and an error code of MTU not supported 
> added. e.g. 
> > a little more pspecified that simply stating the "receiver SHOULD 
> > check that it was recevied in its entirety". Similarly if 
> you copy the 
> > PAD TLV to the reply it may get fragmented in the reverse direction 
> > (presumably there should be a specific "MUST NOT set DF bit in 
> > replies"). The other interesting situation is that you may 
> use PAD TLV 
> > with traceroute mode, and the insertion of downstream 
> mapping TLVs in 
> > the replies will alter the intended MTU of the message. I'm 
> a little 
> > unclear of the value of copy PAD to reply option so if a usage case 
> > could be posted to the list that would be great.
> 
> Ron, care to chime in?
> 
> > 4) Re-iterating the concept of using the FEC stack to infer 
> what level 
> > the addresses in the header refer to. I can envision  messy 
> situations 
> > whereby I was using a VRF loopback address in a packet that TTL 
> > exhausted at a P router (or the ping originated at a CE in a CsC 
> > scenario). WOuld be nice to see a bit more clarity on routing of 
> > replies. Glad to propose some text!
> 
> Please propose text.

OK, suggest inserting para after 4th in section 4.3

If there are more labels than entries in the FEC stack, then it is assumed
that additional labels were pushed onto the stack subsequent to the
insertion of the echo request and use of uniform TTL mode has resulted in a
TTL exhaust with a label stack of depth greater than one.

But this also has implications for steps 1 and 4 of 4.3. 

Label can be valid and PING source address not routable. Hence the MUST
requires a caveat...So I'd suggest....

   1.  Check if there is a FEC corresponding to the current-stack-
       depth.  If there is, go to step 2.  If not, check if the source 
	 address in the ping request is routable, if not silently discard 
	 the packet. If it is, check if the label is
       valid on interface I.  If the label is valid, continue with step 4.
Otherwise
       X MUST send an MPLS echo reply with a Return Code 11, "No label
       entry at stack-depth" and a Return Subcode set to current-stack-
       depth.

Dave