Subject: draft-ietf-pwe3-iana-allocation-07.txt - LAST CALL

From: Stewart Bryant <[email-masked]>
Date: Mon, 01 Nov 2004 23:30:14 +0000

This is the start of a two week last call for

IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-07.txt

Last call will end Tuesday 16th October 2004

- Stewart

---

From: "David Allan" <[email-masked]>
Date: Thu, 4 Nov 2004 16:50:59 -0500

Hi:

A number of us have been working on fault notification for PWs, and have
concluded that we do not need to couple fault direction and fault location
the way it is currently defined for the LDP status TLV in the IANA
allocations draft. There is another proposal but it has not had enough "soak
time" to spring in the middle of a last call. 

Rather than hold up the IANA allocations draft, the suggestion is simply to
remove the status code points we know we will be revising.

So keep
       0x00000000 - Pseudo Wire forwarding ( clear all failures )
       0x00000001 - Pseudo Wire Not Forwarding
 
And lose
       0x00000002 - Local Attachement Circuit ( ingress ) Receive Fault
       0x00000004 - Local Attachement Circuit ( egress ) Transmit Fault
       0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
       0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault

So the IANA registry entry is set up, and we'll provide the requisite
additional code points when it is pinned down...

Any objections?

cheers
Dave

---

From: "Singh, Hardeep (Hardeep)" <[email-masked]>
Date: Thu, 4 Nov 2004 17:59:16 -0500

I agree. Probably the first two can me made mandatory
and the rest optional to implement or be decided later.

We too came to the same conclusion when we implemented
PWE3 circuits as per the draft.

Thanks

Hardeep

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
David Allan
Sent: Thursday, November 04, 2004 4:51 PM
To: [email-masked]'
Subject: FW: [PWE3] draft-ietf-pwe3-iana-allocation-07.txt - LAST CALL

Hi:

So keep
 
And lose

Any objections?

cheers
Dave

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 5 Nov 2004 15:52:13 -0500

I don't think Dave's proposal is to make the others
optional; it was to remove them completely for now.

	--Tom

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 8 Nov 2004 16:31:03 +0200

Tom and all,
IMHO one generic status code indicating that 
the local AC is down is necessary. 

I am not at all sure about the additional refinements.E.g., if a FR DLCI
goes down,would it mean that it has Rx failure or Tx failure?

My 2c.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Friday, November 05, 2004 10:52 PM
> To: Singh, Hardeep (Hardeep)
> Cc: [email-masked]'
> Subject: Re: [PWE3] draft-ietf-pwe3-iana-allocation-07.txt - LAST CALL
> 
> 
> 
> > From: [email-masked] 
[mailto:[email-masked]]On Behalf Of

---

From: "David Allan" <[email-masked]>
Date: Mon, 8 Nov 2004 11:29:24 -0500

Hi Sasha:

We've worked through this in some detail. IMO a split horizon "down" is a
summarization of AIS/RDI which is hard to go backwards from. Communicating
directionality covers all cases when considering all the interworking
possiblities ...including the fact that an ingress PE can also observe
PW/PSN failures (PING or RSVP patherr)...

rgds
Dave

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sasha Vainshtein
> Sent: Monday, November 08, 2004 9:31 AM
> To: 'Thomas D. Nadeau'
> Cc: Singh, Hardeep (Hardeep); [email-masked]'
> Subject: RE: [PWE3] draft-ietf-pwe3-iana-allocation-07.txt - LAST CALL
> 
> 
> Tom and all,
> I am not at all sure about the additional refinements.E.g., 
> if a FR DLCI goes down,would it mean that it has Rx failure 
> or Tx failure?
> 
> My 2c.
> > allocations draft. There is another proposal but it has not 
> had enough 
> > "soak

---

From: Luca Martini <[email-masked]>
Date: Tue, 09 Nov 2004 07:18:10 -0700

David,

This is an allocation draft. If you want something different we'll be 
happy to add it.
If somebody wants to use the messages below , there is no way to prevent 
them from allocating these.
I'm interested in why these are not needed ?
There are many PW types that do not have AIS/RDI support....
How would you have this information propagate ?

Ex. Frame-relay -> IP -> ATM  ?

Luca

---

From: Luca Martini <[email-masked]>
Date: Tue, 09 Nov 2004 07:22:52 -0700

>PW/PSN failures (PING or RSVP patherr)...
So how would a receiving PE detect a Tx PSN error on the transmitting 
side ? ( ex no mpls LSP ? )
So let's say I do not want to use OAM ?

Thanks.
Luca

>>>Subject: Re: [PWE3] draft-ietf-pwe3-iana-allocation-07.txt 
>>>      
>>>
>>- LAST CALL
>>    
>>
>>>
>>optional; it was 
>>>to remove them completely for now.
>>>
>>>	--Tom
>>>
>>>
>>>      
>>>
>>>Subject: FW: [PWE3] draft-ietf-pwe3-iana-allocation-07.txt 
>>>      
>>>
>>- LAST CALL
>>    
>>
>>>
>>>Hi:
>>>
>>>       0x00000002 - Local Attachement Circuit ( ingress ) 
>>>      
>>>
>>Receive Fault
>>    
>>
>>>       0x00000004 - Local Attachement Circuit ( egress ) 
>>>      
>>>
>>Transmit Fault
>>    
>>
>>>So the IANA registry entry is set up, and we'll provide the 
>>>      
>>>
>>requisite 
>>    
>>

---

From: "David Allan" <[email-masked]>
Date: Tue, 9 Nov 2004 09:35:59 -0500

> This is an allocation draft. If you want something different we'll be

What I do not want is a plurality of options and complex state handling.

> them from allocating these.

Except by deprecating them before they fall into common practice.

> I'm interested in why these are not needed ?

Somthing is needed, but not somthing that bundles direction and location
together.

> Ex. Frame-relay -> IP -> ATM  ?

How does ATM figure what to send to the FR AC?
How does FR figure what to send to the ATM AC? 

IMO the requirement is to specify common behavior of the IWF so it only
needs to generate one set of fault states, and handle one set of fault
states from the far end PE.

rgds
Dave

> 
> Luca
> 
> 
> David Allan wrote:
> 
> >Hi:
> >
> >A number of us have been working on fault notification for PWs, and
> >have concluded that we do not need to couple fault direction 
> and fault
> >location the way it is currently defined for the LDP status
> TLV in the
> >IANA allocations draft. There is another proposal but it has not had
> >enough "soak time" to spring in the middle of a last call.
> >
> >Rather than hold up the IANA allocations draft, the suggestion is
> >simply to remove the status code points we know we will be revising.
> >
> >So keep

---

From: "David Allan" <[email-masked]>
Date: Tue, 9 Nov 2004 09:52:55 -0500

> So let's say I do not want to use OAM ?

If I understand the question correctly, if I am not using BFD or 1711, then
it is likely that the ingress PE may know about a fault before the egress,
if it knows at all (e.g. via RSVP path err or a ping failure). in the
patherr case, it is acutally the protocol semantics that the ingress gets
notified and not the egress. In the ping case, you do not really know what
is broken, so the scenario is more ambiguous...

In that scenario (just about wholly dependent on the control plane), I'd
have to use status TLV to communciate that information from the PW ingress
to the PW egress.

Dave

> >>>have concluded that we do not need to couple fault direction and 
> >>>fault location

---

From: Luca Martini <[email-masked]>
Date: Wed, 10 Nov 2004 07:37:37 -0700

Actually in my deployment experience , BFD or 1711 was not needed ( nor 
it existed ), as LDP/OSPF correctly communicated failures even in one 
direction.
The problem I have with you proposed change is that it breaks the 
semantics of this error message. Mainly that is a bit is set , them 
means an error condition. Any bit can be set independently.....
Then all bits can be cleared by sending a 0. To make your proposal work 
we would have to specify that the direction bit is outside this scheme , 
and cannot be sent independently with out an error bit.
Other then saving bits , what is the issue in bundling direction and 
location ?

Thanks.
Luca

David Allan wrote:

>>>>Subject: RE: [PWE3] draft-ietf-pwe3-iana-allocation-07.txt 
>>>>        
>>>>
>>- LAST CALL
>>    
>>
>>>>Tom and all,
>>>>>A number of us have been working on fault notification for 
>>>>>          
>>>>>
>>PWs, and 
>>    
>>
>>>>>simply to remove the status code points we know we will be 
>>>>>          
>>>>>
>>revising.
>>    
>>
>>>>>So keep

---

From: "David Allan" <[email-masked]>
Date: Wed, 10 Nov 2004 11:34:01 -0500

> it existed ), as LDP/OSPF correctly communicated failures even in one 

Not sure where the linkage to BFD & 1711 comes from. Its status TLV being
discussed.

> means an error condition. Any bit can be set 
> independently..... Then all bits can be cleared by sending a 
> 0. To make your proposal work 
> we would have to specify that the direction bit is outside 
> this scheme , and cannot be sent independently with out an error bit.

Correct, 0 is still a "tracks are clear" indication. For those outside some
of the private exchanges, the suggested bits are:

      0x00000000 - Pseudo Wire forwarding ( clear all failures )
      0x00000001 - Pseudo Wire Not Forwarding (fault state)
 	0x00000002 - Pseudo wire administrative down
      0x00000004 - Fault direction (0=forward, 1= reverse)
      0x00000008 - Fault location (0 = PW, 1 = AC)

And Luca is correct in noting that there are invalid combinations. aka 4 or
8 in isolation. ALso forward has precedence over reverse, and PW has
precedence over AC.

> Other then saving bits , what is the issue in bundling direction and 

No real need to communicate detail in multiple fault scenarios, only the
presence of a fault. What the state machines are interested in is presence
of a fault and direction. Location does not matter as far as handling is
concerned, but we've agreed it is useful information, so lumping them
together is simply confusing and IMO obligates implementations to use
multiple messages in multiple fault scenarios. For example an AC receive
fault and a PW transmit fault would require precisely the same actions at
the receiving PE, if I've already got one I do not need to do anything
further, yet to be consistent it would require multiple status messages if
one happened, and then the other happened before the first cleared. I am
downloading fault clearing decisions to the PE receiving status information
by sending it IMO redundant information.

rgds
Dave

---

From: "David Allan" <[email-masked]>
Date: Wed, 10 Nov 2004 11:56:42 -0500

Hi Again

> Other then saving bits , what is the issue in bundling direction and 

A more precise rephrasing of my response to this would be that we have two
choices....

1) We can diseminate all information and then define rules for how each node
interprets that information (PMO) OR

2) We can define rules as to what information is important, and only
communicate that (Proposed FMO)

As there is a time component, the completeness of the information will vary
over time, so if we assume we always distribute  all information, it will
require more messages to keep the nodes in synch. If we define rules as to
what information is important and rules of precedence, we can summarize and
not need to communicate changes that will not alter state.

So it is not about saving bits, it is about saving messages...

cheers
Dave

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 11 Nov 2004 17:36:44 +0200

Dave and all,
Please look at a short question/comment inline.

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Wednesday, November 10, 2004 6:57 PM
To: 'Luca Martini'
Cc: 'Thomas D. Nadeau'; [email-masked]'; Sasha Vainshtein; Singh, Hardeep
(Hardeep)

Hi Again 

As there is a time component, the completeness of the information will vary
over time, so if we assume we always distribute  all information, it will
require more messages to keep the nodes in synch. If we define rules as to
what information is important and rules of precedence, we can summarize and
not need to communicate changes that will not alter state.
[[Sasha]] This assumes that while more information can be generated in
future, we have complete and final knowledge of what is need NOW.  I have
serious doubts regarding validity of such an assumption per se. (indeed,it
if were true, why should new information any be generated? just for fun?) So
Option 1 with  minimal content defined today and an  ability to extend this
content as needed (like the existing processes of IANA allocating new code
points etc.) looks more robust to me.

cheers 
Dave

---

From: "David Allan" <[email-masked]>
Date: Thu, 11 Nov 2004 10:59:09 -0500

Hi Sasha:

>> A more precise rephrasing of my response to this would be that we have
two choices.... 

>> 1) We can diseminate all information and then define rules for how each
node interprets that information (PMO) OR 

>> As there is a time component, the completeness of the information will
vary over time, so if we assume we always 
>> distribute  all information, it will require more messages to keep the
nodes in synch. If we define rules as to what 
>> information is important and rules of precedence, we can summarize and
not need to communicate changes that will not
>> alter state.

[Dave] Taken to its logical conclusion, we need a link state routing
protocol at the PW layer than spans multiple technologies.  In essence the
defined values now are a trivialized link state for a trivial topology,
which being a bitmap has extensibility limits as we need more bits/bytes for
every link/fault/metric we introduce. IMO for a VPWS (P2P service) this far
exceeds the requisite information for interworking with the legacy
technologies under consideration (and I mentally enlarge the set to include
PDH, AAL2 yadda yadda).

The actions required by the "interworked with" technologies only really need
to know of the presence of a fault and direction and that it wass not in
their backyard. Shovelling more information around the network IMO is
superfluous and unnecessary loading of the control plane. That stuff needs
to be handed off to management by the node that originates the notification
for proper trouble ticketing. 

rgds
Dave